GitHub expects the "first" and "last" hash of a commit range the
other way around.
This fixes links when the output is pasted into GitHub issues.
Change-Id: I1c22490b69bc6bec9c0d65307ee80a6b15e96a6c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/322661
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Daco Harkes <dacoharkes@google.com>
The `wsUri` property can be used to identify the target VM service that
a `VmService` instance is connected to.
Change-Id: Ic2ba4674e7b247f808d399aeb64d246a5c791a93
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/322540
Reviewed-by: Kenzie Davisson <kenzieschmoll@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
This was added to prevent accidentally lowering patched members,
but these members are patched before we see them, so they aren't
marked external.
Change-Id: Ib8f7c52c38a3f1e28905798a40319f7aa2994328
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/322502
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
I noticed filterText was incorrect in some cases - for example if label was "MyClass(a)" filterText should be only "MyClass" without the "a".
There was a test for this but it was wrong, it checked filterText was null, even though label contained parens (a null filterText means use label).
I renamed the tests so they moved around a little, but they should be clearer (and more correct) now.
Change-Id: If94f80e8d7dc8b394c49eebb4d7482de2d62c38b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/322461
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@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 --enable-asserts option is not defined in PRODUCT mode, so
args.wasParsed(enableAssertsOption) currently reports an error saying
"Could not find an option named --enable-asserts".
Change-Id: Ic3d0695fc608ccb674141dc5b918d0bdf3dc298e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/322422
Commit-Queue: Derek Xu <derekx@google.com>
Reviewed-by: Ben Konyi <bkonyi@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>
The cache collides with the need to transform the declared representation
type on ExtensionTypeDeclaration.
Closes#53204
Change-Id: I1be3e50dbf932928e08bbf82e1b85ba9d0b29bf5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/322120
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Alexander Markov <alexmarkov@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>
The "additionalExports" are sorted in production code to give stable
output.
Before this CL it did `toString()` on the canonical names which is
O(n^2) because of continued string concatenation.
This CL changes it to sort on the name, going to the parent if it's the
same. This _does_ change the sorting, but should still be stable.
When compiling via the flutter frontend try bot the time spent on
sorting does from ~45 seconds to ~9 seconds (arguable still a lot, but
much better).
This will also speed up flutter testing because it will spend less time
waiting for the frontend.
TEST=Assuming existing tests.
Change-Id: If350b7c2ce49f00b2924732a7fa7eb51c38c8172
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/322280
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Jens Johansen <jensj@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>
This replaces the lowering during SSA which requires manually
registering impacts in multiple places. Instead, we use a kernel
transformation to invoke a helper function which implements the
specified semantics.
Change-Id: I58fd11f6d4d1e4f90d00fa826453de024c8686aa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/319901
Reviewed-by: Stephen Adams <sra@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Mayank Patke <fishythefish@google.com>
Now that ddc, dart2js, and dart2wasm are consistent on toString outputs
for JS objects, we should test to make sure this behavior doesn't
regress.
Change-Id: I2b1b4819e5a2425ae813dc944a4dea7b2147d5bc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/322365
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Auto-Submit: Srujan Gaddam <srujzs@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>
Fixes a breakage caused by https://dart-review.googlesource.com/c/sdk/+/319911. This reverts a mistake in evaluating the argument list for constant errors if it's not even constant.
b/297178967
Change-Id: I88db872025d10dd75e07d1349ceef61bc251cfc2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/322441
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
