Allows you to ask for the types in a library in the declarations phase, and all
the top level declarations in the definitions phase.
Bug: https://github.com/dart-lang/language/issues/2839
Change-Id: If0f8fb777fd8a006d686d457cf5d5ca11fcca9ee
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/311900
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Jake Macdonald <jakemac@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
More details about the design:
https://docs.google.com/document/d/1QDjyY_6wOTOgURwpeYMKU9qEz0gKxx2MUrdruC6Kp6c/edit?usp=sharing
Change-Id: Ie3985d86dca7f5010044ca46c33ca177588c0f69
Bug: #37022
CoreLibraryReviewExempt: Reviewed by vm and api groups. web and wasm groups not affected because FFI isn't on those platforms.
TEST=async_void_function_callbacks_test.dart, ffi_callback_metadata_test.cc, other front end tests
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/305900
Commit-Queue: Liam Appelbe <liama@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
This is done through a synchronized cache between the server and client. When serializing a remote instance, if the server has already serialized that object then it will only send the ID in the future.
These caches currently only live as long as a single macro application in a given phase, but could live longer in the future. They do need to get reliably cleared out to avoid memory leaks though, and the shorter lifetime is easier to manage consistently.
This also allowed me to remove the specialized server/client modes (clients would always only send back IDs previously).
Change-Id: I4e8a102403153829d66b0ac379636f5a95a70cea
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/311420
Commit-Queue: Jake Macdonald <jakemac@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Will be used on dart.dev for customizing the highlight syntax in code blocks to be red underlines rather than yellow highlighting.
Related: https://github.com/dart-lang/site-www/pull/5006
Change-Id: Ib33ee8f6f7307efb649b627dfd9a5d90187cca1a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/311500
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
- Make CorrectionProducer as base class for {Parsed/Resolved}CorrectionProducer.
- Use ParsedCorrectionProducer for ConvertDocumentationIntoLine
- Move sort imports test to used ParsedUnitResult
- Add getter to LintRule to indicate that rule can be run using just parsed AST
Change-Id: Id11466c445e6e505ea752d097b57143f18c47060
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/310484
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Keerti Parthasarathy <keertip@google.com>
Add CONST_FOR_LOOP error message to be clearer that for loops are not
allowed in const contexts.
visitListLiteral handles Constants.
Change-Id: I84465ecf4e1f044c256db45c723fac081b50a40c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/306917
Commit-Queue: Kallen Tu <kallentu@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
I would like to use `Selection` for code completion, but the current
definition of `coveringNode` too often favors the parent node over the
child node. This will effectively cause the cursor to bind more closely
to an identifier token than to other tokens, making it more useful for
code completion.
If we don't like this change for the general case, I can make these changes in a specialized `coveringNodeForCompletion`, but I'd rather not have two approaches.
Change-Id: I39e70f83ad44d50cec55a8bee1f7061dd83746fe
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/310060
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Prior to this change, the first phase of flow analysis, in which flow
analysis "looks ahead" to see which variables are potentially assigned
in each code block, was failing to properly account for variables that
are assigned by pattern assignment expressions. This "look ahead"
information is used by flow analysis to determine the effects of
nonlinear control flow (e.g. to figure out which variables to demote
at the top of a loop, or to figure out which variables are potentially
assigned inside a closure). As a result, it was possible to construct
correct code that would be rejected by the analyzer and compiler, as
well as incorrect code that would (unsoundly) be accepted.
The fix is to call `AssignedVariables.write` from the analyzer's
`FlowAnalysisVisitor`, and from the CFE's `BodyBuilder`, to let flow
analysis know about variable assignments that occur inside pattern
assignment expressions.
Fixes#52745.
Change-Id: I0e6f426a5c5c36f214d5a206aaf5a2de0bfdaac1
Bug: https://github.com/dart-lang/sdk/issues/52745
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/310502
Auto-Submit: Paul Berry <paulberry@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Simple functions can be printed in dart_object_printer.dart.
Moving function reference tests around so they can be easily found together.
Change-Id: If022721f7dca4881d51cbebd65ed968cd89c33c0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/308261
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
Pointer.fromFunction returns a native function pointer to a Dart
function, but has the restriction that the native code must invoke it
on the same thread as the isolate that created it. RawVoidCallbacks is
a new API that is similar to Pointer.fromFunction. It returns a native
function pointer that can be invoked on any thread, with the
restriction that the Dart function must return void. Under the hood we
forward the function args over a port to the target isolate.
We're not 100% settled on the name of the class, but the overall API
design won't change. I'll make sure to get the naming finalized before
submitting this CL. Doc with discussion of naming:
https://docs.google.com/document/d/1z9Rgahoid2AhC9JXwsDAEODvlJS6dvBHCbcGkOxv_ws/edit?resourcekey=0-TbdNiSL-fdwskla02QaPwg#heading=h.te70ikwelbw8
Bug: https://github.com/dart-lang/sdk/issues/37022
Change-Id: Iba98f6f803c52919b942fa054df1060991574c8c
TEST=ffi_async_callback_test.dart
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/308860
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Liam Appelbe <liama@google.com>
Reviewed-by: Marya Belanger <mbelanger@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
This change updates the flow analysis support for field promotion
(which is not yet switched on by default) so that it supports field
accesses inside cascade expressions. The key moving parts are:
- The type hierarchy `PropertyTarget` (which is used by the client to
tell flow analysis whether the target of a property access is
`this`, `super`, or an ordinary expression) now has a new class,
`CascadePropertyTarget`, to represent the situation where the target
of the property access is an implicit reference to the target of the
innermost enclosing cascade expression.
- Flow analysis has two new methods on its API:
`cascadeExpression_afterTarget` and `cascadeExpression_end`, so that
the client can inform flow analysis when a cascade expression is
being analyzed.
- Flow analysis uses its `_makeTemporaryReference` method to track the
implicit temporary variable that stores the target of cascade
expressions. (This method was developed as part of flow analysis
support for patterns, where it creates the data structures necessary
to track the implicit variables that are created as part of pattern
desugaring).
- The "mini-AST" pseudo-language used by flow analysis unit tests now
has a way to represent cascade expressions and method invocations.
- In addition to unit tests for `_fe_analyzer_shared`, `analyzer`, and
`front_end`, there are new language tests in
`tests/language/inference_update_2` to test cascaded field
promotions in end-to-end fashion.
Bug: https://github.com/dart-lang/language/issues/2020
Change-Id: I21353bbc884ed599cb1739cecfb68ad1d975d18b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/309220
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The type arguments have to be explicitly given for collection types,
but this should be doable given they are all constants and only certain
types are allowed.
Change-Id: I2721f37d194d73de1df81302298101adeb87534c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/309460
Commit-Queue: Jake Macdonald <jakemac@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
This reverts commit ea7e014c3c.
Reason for revert: breaks Analyzer tests, CBuild regression.
Original change's description:
> Add wrappers for macro arguments to help with serialization.
>
> In particular this allows us to reproduce type arguments for collections in the
> macro expansion isolate.
>
> The type arguments have to be explicitly given for collection types,
> but this should be doable given they are all constants and only certain
> types are allowed.
>
> Bug: https://github.com/dart-lang/language/issues/2212
> Change-Id: I14a688ed294cf060c004849efa975b5bef053d5b
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/308202
> Reviewed-by: Bob Nystrom <rnystrom@google.com>
> Reviewed-by: Johnni Winther <johnniwinther@google.com>
> Commit-Queue: Jake Macdonald <jakemac@google.com>
> Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Bug: https://github.com/dart-lang/language/issues/2212
Change-Id: I402802c7a1c27f9aee3f23baef8c0deb71ec06e9
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/309284
Commit-Queue: Ilya Yanok <yanok@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
In particular this allows us to reproduce type arguments for collections in the
macro expansion isolate.
The type arguments have to be explicitly given for collection types,
but this should be doable given they are all constants and only certain
types are allowed.
Bug: https://github.com/dart-lang/language/issues/2212
Change-Id: I14a688ed294cf060c004849efa975b5bef053d5b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/308202
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jake Macdonald <jakemac@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Add new diagnostics for mixin subtypes since they can only be 'base'.
Bug: https://github.com/dart-lang/sdk/issues/52686
Change-Id: I8e4d6830c5c735c5b42d7fbe78d197c9506bbf4c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/308806
Commit-Queue: Kallen Tu <kallentu@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Change-Id: I1f29d10a0eff99a98e8e79500288f9766fcc9a64
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/308700
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
With sealed classes we don't need Either2 anymore.
Specific class hierarchies are better, support more than two variants,
don't require additional classes to nest more than one piece of data,
and being supoorted by the language itself, provide exhaustiveness
checking.
Change-Id: I47c7e770d37fb6246f54bcda3600c2fa04fc1d50
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/308540
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
The new annotation is intended to be used on members of class, enum or mixin to opt out the @visibleForTemplate visibility restriction cascaded from class- / enum- / mixin- level.
1. Throw warning if the annotation is added to a invalid target.
2. Update @visibleForTemplate diagnostics logic to opt out members annotated with @visibleOutsideTemplate.
Change-Id: Iec546fc7785cd45f39a1b2a2cc8849ef1cf9d04a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/304825
Reviewed-by: Marya Belanger <mbelanger@google.com>
Auto-Submit: Ludi Zhan <ludizhan@google.com>
Commit-Queue: Ludi Zhan <ludizhan@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Moved a test from `constant_test.dart` to slowly migrate it over.
Change-Id: Id7d0ef0edcfa4fced056ec8fc937b060a74f4468
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/306919
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
Changed the signature of `_getConstant` as a smaller change.
Change-Id: Iac258558a32f11030db53edd658371bacbcc5ee6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/307182
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
If a user promotes a field and then subsequently changes the variable
used to access it, the promotion must be discarded. For example, in
this code:
class C {
int? _i;
}
test(C c1, C c2) {
C c = c1; // (1)
if (c._i != null) { // (2)
print(c._i + 1); // (3)
c = c2; // (4)
print(c._i + 1); // (5)
}
}
The test at (2) promotes `c._i` to non-null, so (3) is ok. But since
`c` is reassigned at (4), (5) should be a compile-time error.
Previously, flow analysis used one promotion key to track `c` and one
promotion key to track `c._i`. The `PromotionKeyStore` associated each
promotion key with a map containing the promotion keys of all of its
properties. So, for example, if the promotion key for `c` was 10 and
the promotion key for `c._i` was 11, the `PromotionKeyStore` would
associate promotion key 10 with the map `{'_i': 11}`, so that each
time `c._i` was accessed, promotion key 11 would be found. In order to
detect the compile-time error at (5), it had to keep track of the fact
that keys 10 and 11 were related, so that the assignment to `c` at (4)
could invalidate the promotion of `c._i`. It accomplished this by
linking together all the related promotion keys in a circularly linked
list, which it would walk at the time of any variable assignment.
This worked, but it required a lot of complex bookkeeping. Also, it
posed problems for integrating field promotion with cascades, for
example, in the following code:
class B {
void f([_]) { ... }
}
class C {
B? _b;
}
test(C c1, C c2) {
C c = c1; // (6)
if (c._b != null) { // (7)
c.._b.f( // (8)
[
c = c2, // (9)
c._b.f(), // (10)
])
.._b.f(); // (11)
}
}
The cascaded access `.._b.f` at (8) should be ok, since `c._b` has
been promoted. But since there is an assignment to `c` at (9), the
promotion should not carry over to (10), and an error should be
reported. However, no error should be reported at (11) because the
cascaded access to `.._b.f` at that location is using the old value of
`c` that was captured at the beginning of the cascade, prior to the
assignment. There's no way to achieve this by invalidation alone,
since the code locations at which the promotion is valid ((8) and
(11), but not (10)) aren't even contiguous.
The solution to the problem is to store property promotion keys in
`SsaNode`s used by flow analysis, rather than in the
`PromotionKeyStore`. Since a fresh `SsaNode` is allocated each time a
variable is assigned, this automatically invalidates any previous
property promotions without the need for any extra bookkeeping. So, in
the first example, at (1), an `SsaNode` is allocated and associated
with the promotion key for `c`. At (2), a promotion key is created for
`c._i` and stored in `c`'s `SsaNode`, and the flow model is updated to
indicate that that key has been promoted to non-null. At (3), that
promotion key is reacalled from the `c`'s `SsaNode`, so the promotion
is still in effect. At (4), a fresh `SsaNode` is associated with
`c`. Since that `SsaNode` doesn't contain any promotion keys yet, at
(5), the access to `c._i` causes a fresh promotion key to be
allocated, with no associated promotions. So the invalidation happens
automatically due to the fact that a new `SsaNode` was created.
Flow analysis doesn't yet support cascades, but here's how the second
example is intended to work: as before, at (6), an `SsaNode` is
allocated and associated with the promotion key for `c`. At (7), a
promotion key is created for `c._b` and stored in `c`'s `SsaNode`, and
the flow model is updated to indicate that `c._b` has been promoted to
non-null. At (8), the `SsaNode` for `c` is captured and saved for
later use. At (9), a fresh `SsaNode` is created and associated with
`c`. That fresh `SsaNode` is consulted at (10), so `c._b` is not
promoted at this point. However, at (11), the previously stored
`SsaNode` is used, so the promotion of `._b` still works.
Change-Id: I64519fbcb2368a37aa18adf35cee0ffd290db9b9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/307140
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
When I was first developing the shared analysis logic for patterns, I
imagined that ordinary variable declaration statements would
eventually be re-interpreted as pattern variable declarations, where
the pattern was simply a variable pattern. In order to facilitate
this, I added support for late variable patterns, so that a
decalration of a late variable could be interpreted as a pattern
variable declaration where the pattern was a "late variable pattern".
In the final implementation, however, this functionality never got
used, except in flow analysis unit tests. Both the analyzer and the
CFE continue to use their old logic for analyzing ordinary variable
declarations (including late variable declarations), and only invoke
the shared logic when the declaration in question is truly a pattern
variable declaration.
In retrospect I believe this is the right approach; ordinary
(non-patterned) variable declarations are common enough that it makes
sense to have separate logic for analyzing theem; invoking the full
generality of pattern variable declarations would simply waste CPU
cycles.
So this CL removes support for late variable patterns from the shared
implementation; this will make future refactoring of flow analysis
logic easier.
Since the flow analysis unit tests *were* taking advantage of the
shared logic for late variable patterns, I had to add some separate
logic to the tests to replicate the old functionality when analyzing
an ordinary late variable declaration. This new logic is only used in
tests.
Change-Id: If51efab3c63bdc20d1f2772c2d2dd1e3f487bb00
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/307183
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Added `_getConstant` to handle the unfortunate `null`s returned by the ConstantVisitor. Refactored other code with this new helper too.
Change-Id: Ic2ce009b78fee151a1a6fa5b2d2621646cbf2c3c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/306672
Commit-Queue: Kallen Tu <kallentu@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This allows more flexibility as we can configure the redirect overtime, compared to the GitHub hosted site which we have less control over. It could even redirect to the old linter site in the meantime if desired.
Contributes to https://github.com/dart-lang/linter/issues/4411 and https://github.com/dart-lang/site-www/issues/4498
Change-Id: I3512002cdf7f62c0338d67cec0d7091f1166479d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/307000
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Commit-Queue: Phil Quitslund <pquitslund@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
make Code a sealed type, and all subtypes base classes
Change-Id: I328b6a25446dc89e88ae2f1c7e137b969f1b86ce
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/306682
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Commit-Queue: Jake Macdonald <jakemac@google.com>
In doing so, made Constant sealed to use in switches.
We want to avoid passing back null as much as possible, so replacing those with InvalidConstant errors.
Change-Id: I5271c15961679316f7cbee9159150e3c7350926f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/306671
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
Previously, flow analysis used three classes to keep track of
information about expressions that have been visited:
- ExpressionInfo, to keep track of information about expressions whose
truth or falsity has an effect on flow analysis (such as `== null`
checks, `is` checks, and combinations thereof those using `&&` and
`||`), as well as identifying the literal expression `Null`.
- ReferenceWithType, to keep track of information about expressions
that represent something that can be promoted (references to
variables and fields), as well as the static type of the expression.
- EqualityInfo, which wrapped ExpressionInfo and ReferenceWithType,
and also redundantly stored the static type of the expression.
These have now been combined into a single class hierarchy with a base
class called `ExpressionInfo`. This makes the code easier to reason
about, because it is no longer necessary to think about which of the
three above classes is needed in a given situation. Also, it helps
prepare for a follow-up CL in which I plan to refactor how flow
analysis gathers this information; the refactor will be easier with
just a single class hierarchy of information to be gathered.
This required a modest expansion of the API to flow analysis to
include more static types, since previously, static types weren't
needed by the ExpressionInfo class.
Change-Id: Id3de8b19049f8d920ebe85ab58c624ae3e55f226
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/304211
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This CL caches `FeatureSet`s (really `ExperimentStatus`s) in the
FeatureSetProvider.
When analyzing rwf-materials (562 contexts) with a filled cache I get
these numbers:
Before:
509,901 instances of `ExperimentStatus`.
Current memory: 3.21GB.
Peak memory: 3.24GB.
Heap: 2.61GB of 2.68GB.
After:
2,246 instances of `ExperimentStatus`.
Current memory: 2.80GB
Peak memory: 2.85GB
Heap: 2.21GB of 2.28GB
Difference:
Instances: -99.55%.
Current memory: -12.77%.
Peak memory: -12.03%.
Heap: -15.32% (used); -14.92% (size).
Change-Id: I3901310eed70733f8bd06ad81bf940b848734723
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/306460
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Changes the return type of ConstantVisitor and make sure everything works
by unwrapping Constants. Added a bunch of TODOs to slowly go through
in follow up CLs.
Change-Id: I5dbb3f4eb6c72daa1fb649b746c8fdc4fb83dadb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/305847
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
Two of these tests (`recordPattern_nullable_beforeAs` and
`recordPattern_nullable_beforeWhen`) verify that the fix for #52439
(Destructuring with explicit type of nullable record is a parsing
error), which causes `(...)? identifier` to be recognized as a
variable pattern, doesn't get confused by the pseudo-identifiers `as`
and `when`, and so it continues to correctly parse `(...)? as ...` as a
cast pattern and `(...)? when ...` as a guarded pattern.
The other two tests (`recordPattern_nonNullable_beforeAs` and
`recordPattern_nonNullable_beforeWhen`) verify that `(...) as ...` and
`(...) when ...` are parsed correctly. These forms were never broken,
but they were not well tested either.
Bug: https://github.com/dart-lang/sdk/issues/52439
Change-Id: I866e1c7a6a8e47e0cd91a1a77654405f395b50da
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/305844
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This CL introduces native assets suport for `dart run` and introduces
`dart build` which is similar to `dart compile` but outputs a folder
instead to that native assets can be bundled with an executable.
Change-Id: Ib6cfb95539f0adee46c99e531e440928c3f72f2b
Cq-Include-Trybots: luci.dart.try:pkg-linux-debug-try,pkg-linux-release-try,pkg-mac-release-arm64-try,pkg-mac-release-try,pkg-win-release-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/267340
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Daco Harkes <dacoharkes@google.com>
It is 2.19 that is different from 3.0, and has different features.
Change-Id: I869ac0de76502f0d2b606e0782fee83f66e86283
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/306127
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Previously, if a record-typed variable pattern lacked a `var` or
`final` keyword, and was followed by one of the tokens `||`, `&&`,
`as`, `?`, `!`, `when`, or `=>`, the parser would fail to recognize
it. This happened because the call to `computeVariablePatternType`
wasn't passing `true` for the optional parameter `required`; that in
turn placed `computeType` in a mode where it believed it was parsing a
potentially ambiguous construct in a top-level declaration, and hence
it would only accept the record type if the variable name was followed
by something that looked like part of a correct declaration (e.g. a
comma).
The fix is to pass `true` for the optional parameter `required` of
`computeVariablePatternType`. This places `computeType` in a mode
where it accepts the record type regardless of what follows it. This
is correct behavior since at the point where a variable pattern is
being parsed, ambiguities have already been taken care of and the
construct being parsed is most definitely a variable pattern.
Fixes#52521.
Change-Id: If20772ad914827a29df45c27eefb382ec1f470d2
Bug: https://github.com/dart-lang/sdk/issues/52521
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/305848
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This is the follow-up to
https://dart-review.googlesource.com/c/sdk/+/282280 that I had
forgotten about.
When analyzing rwf-materials (562 contexts) with a filled cache I get
these numbers:
Before this CL (i.e. parent CL):
99671 ms
98499 ms
99678 ms
With this CL:
85764 ms
86204 ms
86548 ms
Difference at 95.0% confidence
-13110.7 +/- 1256.93
-13.2054% +/- 1.26601%
(Student's t, pooled s = 554.547)
Change-Id: Idcde0c9b92eb34467ce69ee7d552f4a8d035286f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/305681
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
When analyzing rwf-materials (562 contexts) with a filled cache I get
these numbers:
Before this CL (i.e. parent CL):
102829 ms
100934 ms
100991 ms
With this CL:
99671 ms
98499 ms
99678 ms
Difference at 95.0% confidence
-2302 +/- 2041.63
-2.26609% +/- 2.00979%
(Student's t, pooled s = 900.749)
Change-Id: I30025b15f7b8c637d83b2cef234c0e7a602535f3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/305680
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
When analyzing rwf-materials (562 contexts) with a filled cache this
CL removes something like ~1.6 million calls to "isDirectorySync" which -
I think - reads from the filesystem.
On Linux I get this change (on Windows I'm guessing the change is bigger
as the filesystem is often slower):
Before the fix:
111662 ms
112053 ms
112176 ms
With this fix:
102829 ms
100934 ms
100991 ms
Difference at 95.0% confidence
-10379 +/- 1780.48
-9.26997% +/- 1.59023%
(Student's t, pooled s = 785.532)
I.e. it makes it ~10 seconds or ~9% faster.
Change-Id: I42f54b2ff7510365c5a683c993b6b759b35bd152
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/305661
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
So, we don't have to recompute it at every symbol search.
For Flutter repository, searching for 'ButtonStyle' is 40% faster.
SHA: 47fe150674
Description: before
[mean: 56.4][stdDev: 1.471][min: 54.0][max: 61.0]
Description: own files
[mean: 35.0][stdDev: 1.308][min: 33.0][max: 38.0]
Change-Id: Id497bf4117bdfafeeccd04601fd0198e22624c0d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/305843
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Adds an abstract type Constant with two subtypes: DartObjectImpl and
InvalidConstant.
Initial set up for changing the return type in the constant evaluator.
Change-Id: Ia713dee6453937f87d1ae72d3bd240e67d6c13eb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/305500
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Instead of having separate API methods `propertyGet` (for accessing
the properties of an explicit target) and `thisOrSuperPropertyGet`
(for accessing the properties of `this` or `super`), switch to a
single `propertyGet` method. Make the `target` parameter of
`propertyGet` a sealed class (`PropertyTarget`) with three subtypes
representing the three possible kinds of targets:
- `ExpressionPropertyTarget` for an explicit target expression,
- `SuperPropertyTarget` is the target is `super`, and
- `ThisPropertyTarget` if the target is `this`.
Also adjust the API for `promotedPropertyType` to use the new
`PropertyTarget` class for its `target` parameter, rather than a
nullable `target` expression and boolean `isSuperAccess` parameter.
Change-Id: I90535f6d6741776548bc4d60359fd4c40c0fab90
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/304763
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
In a future CL I'd like to filter out whole libraries depending
on whether they could have a match. At this point the search, filtering,
and matching become entangled too much to bind them with outside
code in the server. Instead, it all will be the analyzer's concern.
Change-Id: Iefdadbf92046218b3a2607fbeadd37494522112e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/304841
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
