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>
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>
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>
Previously, the logic for enabling and disabling language features in
flow analysis and type inference tests relied on setters in the
`Harness` class that (a) were mostly unmatched with getters, and (b)
were almost exclusively used in just a single one direction
(e.g. `Harness.legacy` defaulted to `true`, so it was only ever set to
`false`).
Cleaned up so that there are explicit `enable` and `disable` methods
in the `Harness` class to cover all the use cases.
Change-Id: I5ccc8585f803fec634cad1472395ea0d135c87c6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332064
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Lasse Nielsen <lrn@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>
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>
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>
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>
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>
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>
Previously, when field promotion failed due to a conflict with another
declaration in the same library, the client (analyzer or front_end)
was responsible for returning a value of
`PropertyNonPromotabilityReason.isInterferedWith` from
`Operations.whyIsPropertyNotPromotable`. Flow analysis would propagate
this value into a `PropertyNotPromoted` object whose
`documentationLink` getter returned `null`. The client was then
responsible for tracking down all the conflicting fields and getters
and creating the appropriate context messages for them (but this
functionality wasn't implemented yet).
With this change, the `PropertyNotPromoted` is now abstract, with two
subclasses to represent the two cases the client has to handle:
- `PropertyNotPromotedForInherentReason` to cover the case where a
property cannot be promoted due to the fact that it is inherently
not promotable (i.e. it's not final, it's public, it's external,
it's not a field, or it's in a library where field promotion isn't
enabled). In this case the client simply has to generate the
appropriate context message and attach it to the site where the
property is declared, and it can rely on having access to a non-null
`documentationLink` to include in the context message.
- `PropertyNotPromotedDueToConflict` to cover the case where the
property cannot be promoted due to a conflict with some other
property in the same library. In this case the client has to
generate multiple context messages, one for each conflicting
declaration, and it has to associate each one with the appropriate
documentation link from the `NonPromotionDocumentationLink` enum.
The `NonPromotionReasonVisitor` base class has been updated to reflect
this split, so that the logic for handling these two cases is in
separate methods in the client.
The front_end logic for handling non-promotion due to conflict is now
fully implemented. The analyzer logic will be addressed in a follow-up
CL, since it's more complex (it requires plumbing additional data
through the summary file format).
Finally, the nomenclature in the `FieldNameNonPromotabilityInfo` is
adjusted to match the new context messages.
Change-Id: Ieed70d1a3572abbc726ae34584d85c7a8aee0732
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/327712
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Context messages are added to clarify to the user the following
reasons why field promotion might fail:
- Field promotion is not supported prior to Dart 3.2.
- The property in question is not a field.
- The property in question is not private.
- The property in question is an external field.
- The property in question is not a final field.
The final reason why field promotion might fail (interference with
another field or getter of the same name) will be addressed in a
future CL.
Change-Id: Ic860af51d98d8bc84b1103d3ed353b0c4fed39b0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/327707
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Reviewed-by: Morgan :) <davidmorgan@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
- When the shared logic in `field_promotability.dart` decides that a
given field should be non-promotable based on attributes of the
field itself (i.e. because it's public, non-final, or external), it
returns information to the caller about the reason for
non-promotability.
- This information is recorded by the analyzer and CFE, and delivered
back to flow analysis in response to a new callback method,
`whyIsPropertyNotPromotable`. Flow analysis records this information
in the `PropertyNotPromoted`, which is delivered to clients when a
compile-time error occurs due to a property access not being
promotable. This ensures that the appropriate
`http://dart.dev/go/non-promo-...` link will be associated with the
context message. In a future CL, the context messages themselves
will be updated to match the link.
- The shared logic in `field_promotability.dart` also collects, for
each field name that isn't promotable, all the reasons why that
particular field name is non-promotable, in a new data structure,
`FieldNameNonPromotabilityInfo`. In a future CL, this data structure
will be used to explain to the caller situations in which a field is
non-promotable due to interference from other fields or getters with
the same name.
Change-Id: I89ad102a4bec071bf59374971a8d83b061d4ec1d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/327901
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This change updates `FlowModel.promotionInfo`, the primary data
structure used by flow analysis to track program state, so that
instead of being a `Map<int, PromotionModel<Type>>`, it is represented
by a new data structure called a `FlowLink`, an immutable data
structure describing program state in a way that's particularly
optimized for flow analysis's usage patterns.
Like a map, a `FlowLink` data structure represents a collection of
key/value pairs (where the keys are integers), however instead of
storing the keys and values in a hashtable, each `FlowLink` object
contains a single key/value pair and a pointer to a previous
`FlowLink` object. The value associated with a given key can be looked
up by starting with the current `FlowLink` and walking backwards
through the linked list of `previous` pointers until a matching key is
found. (An empty map is represented by `null`). This makes it an
`O(1)` operation to update the promotion state associated with a
single promotion key (an operation that flow analysis performs
frequently), since all that is required is a single allocation.
If the `previous` pointers are regarded as parent pointers, all the
`FlowLink` objects produced by a given run of flow analysis form a
tree that mirrors the dominator tree of the code being analyzed.
To optimize reads of `FlowLink` data structures, there is a
`FlowLinkReader` class that keeps track of a lookup table reflecting
the implicit map represented by a given `FlowLink` object; this table
can be updated to reflect a different `FlowLink` object in `O(n)`
time, where `n` is the number of edges between the two `FlowLink`
objects in the tree. Since flow analysis is based on a depth-first
traversal of the syntax tree of the code being analyzed, it has a high
degree of tree locality in the `FlowLink` objects it needs to be able
to read, so these `O(n)` updates do not consume much CPU.
The `FlowLinkReader` class is also able to compute a difference
between the program states represented by two `FlowLink` objects, in
`O(n)` time, where `n` is the number of edges between the two
`FlowLink` objects in the tree. This is used by flow analysis to
compute the program state after a control flow join, so that it does
not need to spend any time examining promotion keys that are unchanged
since the corresponding control flow split.
For more information about the `FlowLink` data structure and how it
works, see the comments in `flow_link.dart`.
This change improves the performance of CFE compilation fairly
substantially:
instructions:u: -0.8167% +/- 0.0007% (-158214865.67 +/- 130252.25)
branches:u: -0.4694% +/- 0.0009% (-18575169.00 +/- 37220.97)
branch-misses:u: -1.0009% +/- 0.7189% (-575742.67 +/- 413521.70)
Change-Id: Ia87458ee599977e6efdc9f0e7aa283a41f84f616
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/326900
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Morgan :) <davidmorgan@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
`FlowModel.promotionInfo` is currently a map from integer promotion
keys to PromotionModel data structures. This is inefficient because
FlowModel is an immutable data structure, so whenever the promotion
state of a variable changes, the map must be duplicated. In a
follow-up CL I will be changing `FlowModel.promotionInfo` to a much
more efficient data structure. However, that data structure will
require some extra plumbing. For ease in code review, I'm doing the
extra plumbing first, as its own CL.
This CL makes the following changes:
- Removes unnecessary null checks from the `FlowModel.withInfo`
constructor. These null checks are no longer needed because all the
clients of flow analysis are now fully null safe. This change is not
strictly necessary; it's just a long-overdue clean-up.
- Adds a `helper` argument (of type `FlowAnalysisHelper`) to
`FlowModel.conservativeJoin`, `FlowModel.declare`, and
`FlowModel.infoFor`, `FlowModel.inheritTested`, and
`FlowModel._updatePromotionInfo`. This is needed because these
methods will need access to `FlowAnalysisHelper` in order to read
and update the new data structure.
- Removes the `typeOperations` argument of `FlowModel.inheritTested`,
since it can be easily obtained from the new `helper` argument.
- Changes `FlowModel._updatePromotionInfo` to a public method
annotated with `@visibleForTesting`. This will be needed by flow
analysis unit tests to create the new data structure.
Note that this change causes a small regression in the performance of
CFE compilation, due to the extra `helper` arguments:
instructions:u: 0.0693% +/- 0.0008% (13413234.33 +/- 155671.09)
branches:u: 0.0886% +/- 0.0012% (3502620.67 +/- 45724.97)
The follow-up CL that switches to a more efficient data structure will
result in a performance improvement roughly an order of magnitude
larger.
Change-Id: I21c13fb817f05281b558f0473119473a26ea0fb8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/326860
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This makes it easier to see at a glance which messages need to be
supported by the website.
I've included the new links that I intend to support as part of the
new "field promotion" feature.
Bug: https://github.com/dart-lang/sdk/issues/53102
Change-Id: I67ad47c5a00db9807a6c726677a06427cdbe02c2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/325803
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Bug: b/286184681
Change-Id: I903528c4adfbc576644aec7541903df6b9633e26
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/325523
Reviewed-by: Jonas Termansen <sortie@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Alexander Thomas <athom@google.com>
This passes the first token of these top level declaration directly
to the endX listener method.
In the CFE this is used to ensure that can handle the new modifiers in
the textual outline. Furthermore, support for extension types is added
and having an "unknown chunk" now results in an error. The latter should
help us keep the textual outline up-to-date wrt new features.
Change-Id: I813d6162b6cba0a2bf550ed33a6091abf9bf49f8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/324702
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
+ remove listener events for hide/show used for the old, now deleted,
extension type experiment.
Change-Id: I5258ce10507305a993b36bf75fd781bf1f16ddff
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/326341
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This updates the generator of experimental flags to only refer to one
location for the current default language version.
Semantically the change does nothing, but it could make CLs that bump a
version smaller and easier to revert/patch.
Change-Id: I1c18c8e8105dfb33a302949ad2cfa159dae2addf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/325660
Reviewed-by: Alexander Thomas <athom@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
External final fields are equivalent to getters whose implementation
is provided outside of Dart code. As such they're not guaranteed to be
stable, so they shouldn't be promotable.
It turns out that the CFE was already correctly classifying them as
non-promotable (because it de-sugars them into getters prior to
computing promotability). This CL fixes the analyzer.
Fixes https://github.com/dart-lang/sdk/issues/53426.
Bug: https://github.com/dart-lang/sdk/issues/53426
Change-Id: Icdd897cdbdf0da0a69ea704a245c0b428070b95e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/324340
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Refactors BlockKind to pass an explicit template/message instead
of injecting words directly into the message which leads to
grammatically incorrect english in the output message.
Change-Id: I3b91abf2e5a748f3dfca2cc0a6c877e77b3ad7d2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/322121
Reviewed-by: Jens Johansen <jensj@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Will follow up with tests once we agree on the API. At the same time I will handle translating any normal runtime errors into error diagnostics.
Bug: https://github.com/dart-lang/language/issues/3234
Change-Id: I2fc22af088f0e50b1877022aa793337850257804
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/317221
Commit-Queue: Jake Macdonald <jakemac@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
When entering visiting a subpattern of an object pattern, the flow
analysis engine now updates `_FlowAnalysisImpl._scrutineeReference` to
a `_PropertyReference` referring to the property being matched; this
ensures that if the subpattern match implies a type promotion, and the
property in question is promotable, the type promotion will be applied
to the property.
Also, if the property has already been promoted at the time of entry
to the subpattern, the promoted property type is used as the matched
value type.
Includes unit tests and language tests for the new functionality.
Fixes#53100.
Change-Id: I6d28e9a7d188bf1136e8517d6aa06af3b4c31c69
Bug: https://github.com/dart-lang/sdk/issues/53100
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/323001
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Previously, we used a switch statement in
`_FlowAnalysisImpl._handleProperty` with pattern matching. In a
follow-up CL, I will be shifting this logic to the callers of
`_handleProperty`. Implementing it as a virtual method dispatch rather
than a switch statement will mean that less code will need to be
duplicated.
There is a small performance improvement in CFE compilations:
instructions:u: -0.0192% +/- 0.0010% (-3708144.33 +/- 200427.86)
branches:u: -0.0332% +/- 0.0013% (-1309699.00 +/- 51985.25)
Change-Id: I3767917035ff0c462aa53f8023e72ce061211f2e
Bug: https://dart-review.googlesource.com/c/sdk/+/320701
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/320701
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Prior to this change, the SSA node stored in `PromotionModel.ssaNode`
was only correct for promotion models that represented variable
references. If a promotion model represented a promotable field, its
`ssaNode` pointed to a bogus SSA node. This had two undesirable
effects:
- It meant that `FlowModel.rebaseForward` needed to contain a hack to
prevent it from looking at the bogus SSA node for a promotable
field, and falsely concluding that the field's value had been
reassigned (which is impossible for promotable fields)--see
https://dart-review.googlesource.com/c/sdk/+/321752.
- It meant that if a promotable field was used as a scrutinee in a
refutable pattern match, the promotion logic would look at the bogus
SSA node for the field, and falsely conclude that its value had been
reassigned, preventing field promotion from working during pattern
matching.
This change ensures that the correct SSA node is always stored in
`PromotionModel.ssaNode`, and removes the hack in
`FlowModel.rebaseForward`. This required some re-ordering some of the
logic for control flow joins, to ensure that when a join creates a
fresh promotion model for a property, it has already created the
corresponding `_PropertySsaNode` (previously, it created the
`_PropertySsaNode` afterwards, but that is too late since the
`PromotionModel` class is immutable).
Unit tests and language tests are introduced to validate the newly
fixed behavior for promotable fields used as a scrutinee in a
refutable pattern match.
Also, the uses of `FlowModel.infoFor` in queries such as
`getMatchedValueType`, `isAssigned`, `isUnassigned`, and
`promotedType` were changed to simple map lookups, to prevent bogus
SSA nodes from being created and then immediately discarded. This
resulted in a fairly significant boost to CFE compilation speed:
page-faults:u: -1.2664% +/- 0.1535% (-2531.33 +/- 306.73)
instructions:u: -0.6210% +/- 0.0009% (-119891846.00 +/- 180585.35)
branches:u: -0.6765% +/- 0.0014% (-26637478.67 +/- 54272.64)
branch-misses:u: -0.9562% +/- 0.8909% (-548444.00 +/- 510991.65)
Change-Id: I30f82e8a4ba11236735258077d61d36717fa32c2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/322443
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
These tests fill a coverage gap in the flow analysis unit
tests. Previously we tested that "join" variables were created by
logical-or patterns and switch cases that share a body, but we didn't
have any tests to verify that those variables could be used.
We now verify that those variables can be read from and promoted.
Change-Id: Ic8948cd307edff429aea9007183d65cc3a770ef3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/322360
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
The method `FlowModel.infoFor` does the same thing.
Change-Id: Ifc46289097943bb3873bc503920f765c6a168ca7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/322225
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
When the result of an `is` test or null check is stored in a boolean
variable, and later recalled for use in flow control, the flow models
that were computed at the time the variable was stored need to be
updated to reflect any further change to flow state that happened
between the test and the usage. This is done by
`FlowModel.rebaseForward` method. `rebaseForward` takes two flow
models as input: `this`, which represents the flow state that was
computed at the time the condition variable was stored, and `base`,
which represents the flow state at the time the condition variable is
recalled.
Flow analysis adds promotion keys for variables to the flow state at
the time their declarations are encountered, and in certain
circumstances removes them after they go out of scope. But for
properties, it only adds promotion keys when the promotion occurs. So
prior to the addition of field promotion, if `this` contained a
promotion key that wasn't present in `base`, that could only mean that
the promotion key was associated with a variable that had gone out of
scope; accordingly, it was safe for `rebaseForward` to simply ignore
that key. (It did so implicitly, by only ever examining the promotion
keys in `this`). But with the addition of field promotion, it is now
possible that the promotion key represents a property that was
promoted in `this`, and hence the promotion needs to be kept. This CL
adds the necessary logic to keep the promotion.
In addition, there is a subtle difference in the relationship between
the `PromotionModel` and `SsaNode` data structures for local variables
versus properties. For local variables, the promotion key is
determined solely from the variable name; then, this promotion key is
looked up in the current `FlowModel` to obtain a `PromotionModel`, and
the `PromotionModel` contains a prointer to the `SsaNode`. For
properties, the property name is looked up in the
`promotableProperties` map of the parent `SsaNode`; this points to a
`_PropertySsaNode`, which contains the promotion key, and when this
promotion key is looked up in the current `FlowModel` to obtain a
`PromotionModel`, that `PromotionModel` contains a pointer to a bogus
`SsaNode`.
For local variables, the `SsaNode` pointed to by the `PromotionModel`
is important, because if it's different between `this` and `base`,
then the variable in question received a new value between the time
the condition variable was stored and the time the condition variable
was recalled; therefore the promotion should be disregarded. However,
for properties, the `SsaNode` pointed to by the `PromotionModel` is
bogus, so if it's different between `this` and `base`, that shouldn't
block promotion. This CL adds the necessary logic to avoid the
`SsaNode` check for properties.
This situation is very confusing so I've added more detail to the
comment above `PromotionModel.SsaNode` explaining it. In a future CL I
will try to clean up the confusing situation by eliminating the bogus
`SsaNode`s pointed to by `PromotionModel`s for properties.
Fixes https://github.com/dart-lang/sdk/issues/53273.
Bug: https://github.com/dart-lang/sdk/issues/53273
Change-Id: I1d528e25de1eb2ed63d0ee1a00faa5ad5b5061ca
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/321752
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This expands the existing recovery for class headers to handle
invalid, out-of-order, and duplicate clauses in extension type
declaration headers.
Change-Id: I7b33b91cc718e4c0673137121b8d083fa0ef1562
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/321900
Reviewed-by: Jens Johansen <jensj@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
The `merge` operation is equivalent to a `join` operation followed by
an `unsplit` operation, so there is no real benefit to having both
`merge` and `join` as separate methods. Removing `merge` will make it
easier to refactor the behavior of `join` in follow-up CLs.
Change-Id: I4a42cdd1cb2e795dcfeae86703fe5d3356c131ce
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/322140
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
