After simplifying the handling of annotations in the kernel loader in
[0] we no longer need to use handle-based access to pragmas.
Also use bit field to represent detected pragmas.
[0] https://dart-review.googlesource.com/c/sdk/+/290502
TEST=ci
Change-Id: I2e21c9e96accce1580964e617f05e4316563b463
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/318260
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
When evaluating an expressino at a breakpoint that's inside a closure,
the closure may refer to anything it closes over. That includes the
`this` from an enclosing method.
So depending on whether a closure's parent chain is an instance method
or a static method, the expression evaluation function is going to be an
instance method or a static method.
=> We walk up the parent chain to determine the correct enclosing class.
=> This avoids making a Type object with a cid from a top-level class (see [0])
Handling this correctly will now try to get the `this` when invoking an
eval function that has an enclosing instance method. Though we may often
have "<optimized out>" the `this` (e.g. due to not capturing it in
closure context chain).
=> We still allow running the expression evaluation function in this
case, but only if the expression being evaluated doesn't access `this`.
A similar issue occurs when trying to use variables in the eval
expression that the closure didn't capture. This results in a confusing
CFE compile-time error. This is a separate issue and tracked in [1].
=> We update the test to distinuish the cases that this CL makes passing
and those that are failing due to [1].
Fixes [0] https://github.com/dart-lang/sdk/issues/53061
See also [1] https://github.com/dart-lang/sdk/issues/53087
TEST=Fixes part of service/evaluate_activation_test failures
Change-Id: I3bb24e7338c7b2f12d5340311d944cb59a455641
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/317540
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
There are two changes here that account for ~5% of the cycles spent compiling large programs:
1) Calls to 'runtimeType' (specifically _AbstractType.toString) are expensive and CodegenPhase.name calls this 2/3 times per member in the target program.
2) ModularNamer._jsVariableReservedCache is a late final field that gets instantiated for every namer in the program, of which there is one per member in the target program. All the subsets are static and so _jsVariableReservedCache can be static as well. Ideally this would be const but const sets cannot have duplicate strings and the various subsets have some overlaps.
Change-Id: Iefc294145feebe397b2db84a5f49906c6b1372a1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/317981
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
Using setProperty triggers assertInterop, which prevents a Dart
Function from being boxed.
Change-Id: Ifa8a068abb7191ccb1c50f2733e6d85df411c945
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/317847
Commit-Queue: Joshua Litt <joshualitt@google.com>
Auto-Submit: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Joshua Litt <joshualitt@google.com>
Change-Id: I561a87b7cac16f13b680337bbef3d53a18ee9041
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/317962
Commit-Queue: Jackson Gardner <jacksongardner@google.com>
Auto-Submit: Alexander Thomas <athom@google.com>
Reviewed-by: Jackson Gardner <jacksongardner@google.com>
These nodes are necessary to inform the back ends that the static type
of the getter access is different from the static type of the
field. Without them, some back ends may make unsound assumptions about
the generated code, leading to runtime failures.
Fixes https://github.com/dart-lang/sdk/issues/50499.
Change-Id: Iad32c9b660d6e3e3106c3143c5139c8a6bd0b67b
Bug: https://github.com/dart-lang/sdk/issues/50499
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/317260
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Currently if a class method is annotated with @visibleOutsideTemplate,
only the method declaration can be referred outside template files, but
not the enclosed method parameters.
Meanwhile, a method parameter is not a valid target for
@visibleOutsideTemplate, because it's not a member of Class, Enum or
Mixin.
Update the logic so that enclosed elements of a @visibleOutsideTemplate
element will also be @visibleOutsideTemplate.
Change-Id: Ifcfaa47a154fe6e2b15fae07f3a30e8a543916a2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/317846
Commit-Queue: Ludi Zhan <ludizhan@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
My plan is to checkout the SDK when analyzer 6.0.0 was published,
then cherry-pick this commit, and publish analyzer_plugin.
In a test run, the package analyzes cleanly and all tests pass.
Bug: https://github.com/dart-lang/sdk/issues/52769
Change-Id: I10661dd665c612eeb82977bdf2f8432e022044b6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/317802
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Behaviour seems to be as expected. In the examples, `new B(A.instance);` can be made const and don't produce any errors, meaning that the `prefer_const_constructors` lint can trigger.
The regression doesn't exist anymore.
Added some tests to prevent future regression.
Fixes https://github.com/dart-lang/sdk/issues/31835
Bug: https://github.com/dart-lang/sdk/issues/31835
Change-Id: I0e192709a17d12eb6395f4585b65fce4628f7d12
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/316844
Commit-Queue: Kallen Tu <kallentu@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This reverts commit 95474f44f1.
Reason for revert: getline seems to be missing on some platforms we target (e.g. Android).
Original change's description:
> [vm/service] Use getline to read /proc/self/smaps
>
> Previously the code was using `fgets` with a fixed
> size buffer. This lead to a confusing behavior where
> lines longer than 255 characters would be read
> in multiple chunks and cause crashes in the parsing code.
>
> Additionally make extraction of the path component slightly
> more robust by searching for path field forward rather than
> backwards. Path might contain white space and searching
> backwards might stumble on that.
>
> TEST=manually
>
> Change-Id: I1d23df4a79b04721d3a812e19eae9b8ad0e955fa
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/317683
> Commit-Queue: Slava Egorov <vegorov@google.com>
> Reviewed-by: Ben Konyi <bkonyi@google.com>
Change-Id: Iaa6886f318884f9ac17487b2ab59621bb44fcb3b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/317781
Auto-Submit: Slava Egorov <vegorov@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Previously the code was using `fgets` with a fixed
size buffer. This lead to a confusing behavior where
lines longer than 255 characters would be read
in multiple chunks and cause crashes in the parsing code.
Additionally make extraction of the path component slightly
more robust by searching for path field forward rather than
backwards. Path might contain white space and searching
backwards might stumble on that.
TEST=manually
Change-Id: I1d23df4a79b04721d3a812e19eae9b8ad0e955fa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/317683
Commit-Queue: Slava Egorov <vegorov@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
The method `InferenceVisitorBase.getFunctionTypeForImplicitCall` was
only being in one circumstance: when a method invocation resolves to a
field or getter which needs a runtime covariance check, it was being
used to determine what type should be used for the covariance
check. Its effect was to either return the type unchanged (in the case
where it was already a function type) or, in the case where the type
was an interface, to look up the type of the interface's `.call`
method.
But this is not the behavior we want. For a covariance check, the
right thing to do is simply to verify that the result of the getter
invocation satisfies the getter's static type (with appropriate
substitutions). It doesn't matter whether the type in question is an
interface type, a function type, or some other type.
Fixes https://github.com/dart-lang/sdk/issues/53089.
Change-Id: I064bea0fdf0ba3695f6ce51e9b84cc1421061a2e
Bug: https://github.com/dart-lang/sdk/issues/53089
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/317360
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Currently a function, its tear-off generator, and the trampolines of the
tear-offs have the same Wasm name. This makes it difficult to
distinguish them in .wat outputs.
This CL gives them separate names:
- Function names are same as before: "f".
- Tear-off generators have the suffix "tear-off": "f tear-off".
- Trampolines have the suffix "tear-off trampoline":
"f tear-off trampoline".
Change-Id: I2459f7d2fd359e72ace7cc4e7790a3e6e64d1f31
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/317640
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Commit-Queue: Ömer Ağacan <omersa@google.com>
This CL introduces handling of promotions of the form `x is T` where
`x` has static type `X?`, `X` is a type variable, and `T` is
non-nullable. They are treated as an equivalent of `x == null || x is
T`, effectively resulting in the static type of `x` being `X & T` in
the promoted code.
Closes https://github.com/dart-lang/sdk/issues/52973
Change-Id: Ibfa6e32e14202651db09cfb4fbbdec864552b96a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/316381
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Chloe Stefantsova <cstefantsova@google.com>
Avoid throwing `CONST_CONSTRUCTOR_PARAM_TYPE_MISMATCH` for any type of `InvalidType`s since we don't want to do any type checking if we don't actually know the types.
This is another fix for breakages in g3.
b/294003447
Change-Id: Id38de02cfd0317dc6771944bec0f54efb2614494
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/317500
Commit-Queue: Kallen Tu <kallentu@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This change cannot be landed until a new version of devtools_shared is published and rolled into the SDK so that it can be depended upon here.
Change-Id: Ia7196fb8c12e980220ee2c2749a979f6359452a9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/305043
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Kenzie Davisson <kenzieschmoll@google.com>
Dart 3's minimum language version is 2.12. google3's is 2.9.
Change-Id: Icd892b0fcec7f2ce9fa813a108519c0bbbd29a52
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/317040
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Fix the service type `TypeParameters` to recognize it is a heap object.
Exhaustively test that the service client libraries can handle inflating all types produced by the VM. Compare vm/cc/PrintJSON, which exhaustively tests the VM can generate any type.
TEST=ci
Bug: https://github.com/dart-lang/sdk/issues/52893
Change-Id: Id1f080656ef6e999e69f2ebb5b9961fa3b461e4a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/316862
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
