The CFE constructor tear-off lowerings introduce extra static methods.
Tear-off constants refer to them as `StaticTearOffConstant`s. They
just forward the call to the actual generative, factory or
redirecting factory constructors.
We can avoid these intermediary methods by not using the CFE lowerings.
Change-Id: I1dc1203d6b3023cf1f13bc204a2628ec8a3aebc4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/508562
Reviewed-by: Nate Biggs <natebiggs@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
This adds a VariableDeclaration node which is used in ForStatement instead of VariableStatement.
This is a step towards removing the initializer from Variable. Long term, VariableDeclaration will own the initializer expression for variables and function parameters will have a defaultValue property instead of using the initializer property for the default value.
TEST=existing
Change-Id: I4a663eeb6006a0f9f098fb2b3e3b502d2ae583b0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/505681
Reviewed-by: Stephen Adams <sra@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
This separates VariableDeclaration from Statement. VariableDeclaration no longer implements Statement and variable declared in a block or in a for-statement are now wrapped by a VariableStatement.
Currently there are two VariableStatement implementations; LegacyVariableStatement for variables in the current model, called LegacyVariable, and VariableInitialization for variables used in the new, still experimental, encoding that supports scope computation.
This CL is a step towards realigning the AST nodes to the new model in which each kind of variable has its own distinct subclass. (LocalVariable, PositionalParameter, NamedParameter, SyntheticVariable, etc.)
Note that it is not the intent to use VariableStatement in ForStatement going forward but that will be handled in a follow-up.
TEST=existing.
Change-Id: I5b309cd62c9b138f95b74fb054686edffa49a393
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/502681
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This is a reland of commit e7dbd6ba48
Original change's description:
> [dart:js_interop] Make JSFunction and JSExportedDartFunction generic
>
> Fixes https://github.com/dart-lang/sdk/issues/54557
>
> The generic type in JSExportedDartFunction corresponds to the
> static type of the function it wrapped, whereas for JSFunction,
> it's purely a descriptor of the JS function.
>
> When calling JSExportedDartFunction, a cast is now introduced
> to cast it to T.
>
> When calling isA, the type in JSExportedDartFunction is passed
> along to check that the value that is wrapped is that function
> type. Because the T in JSFunction is descriptive, e.g.
> isA<JSFunction<int Function()>>() does no such check.
>
> ____
>
> Also cleans up:
>
> - isA<JSTypedArray>() logic to use intrinsic functions
> - some expectation files to be consistent for both dart2js and ddc.
>
> CoreLibraryReviewExempt: Backend-specific library with needed reviews.
> Change-Id: I1a55c4386e416fa4ccabe06ac5051f41c2e2e95a
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/496820
> Reviewed-by: Lasse Nielsen <lrn@google.com>
> Commit-Queue: Srujan Gaddam <srujzs@google.com>
> Reviewed-by: Martin Kustermann <kustermann@google.com>
CoreLibraryReviewExempt: Reland.
Change-Id: I29d706aa4967fd80390e8cb37f8144603ec007f5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/498100
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Call sites targeting a procedure annotated with `external-effect` will
not produce any code, including the argument which will not be
evaluated.
However, the single parameter will be treated as 'live' for the purposes
of any global analysis the backends do. This is useful for things like
protobuf shaking where a user may want to retain certain protobuf
messages without actually emitting the code that retains those messages.
Today this functionality is available internally in the vm and wasm SDK
libraries. dart2js has similar functionality represented via the
opaqueTrue and opaqueFalse booleans (which will cause conditional
branches to get shaken after analysis). This will replace dart2js's
opaque(True/False).
This also adds validation to the frontend to ensure a method annotated
with 'external-effect' is well-formed.
Change-Id: If1c4096673e655c58fe7638840a16125003e7809
Tested: Backend tests for codegen were added. A frontend test was added for the validation. A language test was added to confirm the behavior.
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/476020
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
This reverts commit e7dbd6ba48.
Reason for revert: Broke flutter_analyze
Original change's description:
> [dart:js_interop] Make JSFunction and JSExportedDartFunction generic
>
> Fixes https://github.com/dart-lang/sdk/issues/54557
>
> The generic type in JSExportedDartFunction corresponds to the
> static type of the function it wrapped, whereas for JSFunction,
> it's purely a descriptor of the JS function.
>
> When calling JSExportedDartFunction, a cast is now introduced
> to cast it to T.
>
> When calling isA, the type in JSExportedDartFunction is passed
> along to check that the value that is wrapped is that function
> type. Because the T in JSFunction is descriptive, e.g.
> isA<JSFunction<int Function()>>() does no such check.
>
> ____
>
> Also cleans up:
>
> - isA<JSTypedArray>() logic to use intrinsic functions
> - some expectation files to be consistent for both dart2js and ddc.
>
> CoreLibraryReviewExempt: Backend-specific library with needed reviews.
> Change-Id: I1a55c4386e416fa4ccabe06ac5051f41c2e2e95a
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/496820
> Reviewed-by: Lasse Nielsen <lrn@google.com>
> Commit-Queue: Srujan Gaddam <srujzs@google.com>
> Reviewed-by: Martin Kustermann <kustermann@google.com>
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Change-Id: I98447c8c95906feb7f8f1a57859a24fc8e4966d6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/498080
Commit-Queue: Alexander Aprelev <aam@google.com>
Auto-Submit: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Fixes https://github.com/dart-lang/sdk/issues/54557
The generic type in JSExportedDartFunction corresponds to the
static type of the function it wrapped, whereas for JSFunction,
it's purely a descriptor of the JS function.
When calling JSExportedDartFunction, a cast is now introduced
to cast it to T.
When calling isA, the type in JSExportedDartFunction is passed
along to check that the value that is wrapped is that function
type. Because the T in JSFunction is descriptive, e.g.
isA<JSFunction<int Function()>>() does no such check.
____
Also cleans up:
- isA<JSTypedArray>() logic to use intrinsic functions
- some expectation files to be consistent for both dart2js and ddc.
CoreLibraryReviewExempt: Backend-specific library with needed reviews.
Change-Id: I1a55c4386e416fa4ccabe06ac5051f41c2e2e95a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/496820
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
This CL is part of an effort to bump the SDK requirement to `3.12.0-0`
for all the packages in `pkg` that are not published to `pub`, so that
we can get better testing of the "private named parameters" feature.
(Packages that *are* published to `pub` can't be safely bumped yet,
because SDK 3.12 hasn't been released, and I don't want to block those
packages' ability to publish useful updates to customers.)
This change covers the following packages, which are owned by
OWNERS_WEB:
- pkg/_js_interop_checks/pubspec.yaml
- pkg/compiler/pubspec.yaml
- pkg/dart2js_info/pubspec.yaml
- pkg/dart2js_runtime_metrics/pubspec.yaml
- pkg/dart2js_tools/pubspec.yaml
- pkg/dev_compiler/pubspec.yaml
- pkg/js_ast/pubspec.yaml
- pkg/js_runtime/pubspec.yaml
- pkg/js_shared/pubspec.yaml
- pkg/modular_test/pubspec.yaml
- pkg/node_preamble/pubspec.yaml
- pkg/reload_test/pubspec.yaml
- pkg/sourcemap_testing/pubspec.yaml
Changes to `pubspec.yaml` files were made manually.
Changes to `.dart` files were made automatically (with a few
exceptions), using `dart fix` to migrate to using private named
parameters where it is possible to do so without changing
semantics. Note that this migration is conservative; see
https://github.com/dart-lang/sdk/issues/58607 for details.
The exceptions are:
- pkg/compiler/test/codesize/swarm/DataSource.dart
- pkg/compiler/test/codesize/swarm/Views.dart
- pkg/compiler/test/codesize/swarm/swarm_ui_lib/layout/GridLayout.dart
- pkg/compiler/test/codesize/swarm/swarm_ui_lib/touch/ClickBuster.dart
- pkg/compiler/test/codesize/swarm/swarm_ui_lib/touch/Scrollbar.dart
- pkg/compiler/test/codesize/swarm/swarm_ui_lib/touch/Scroller.dart
- pkg/dev_compiler/test/sourcemap/testfiles/next_through_is_and_as_test.dart
For these files, there was no need to migrate to using private named
parameters, however the language version bump caused flow analysis to
improve, so some additional dead code was detected that hadn't been
detected previously. I reasoned that it's better to minimize changes
to testcases, so rather than deleting the dead code, I just added
`ignore` comments to prevent the bots from failing.
Change-Id: I04f5280d7cedef0a6f0ef718133a03d06a6a6964
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/487945
Auto-Submit: Paul Berry <paulberry@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Fixes https://github.com/dart-lang/sdk/issues/62626
Moves the ffi check out of _js_interop_checks and into its
own dart2wasm-specific check, and then gates any ffi
transforms based on whether we're allowed to import it.
This lets the dry-run run without any potential crashes
related to transforming ffi code. A new dry run enum is
added as well to disambiguate JS interop checks from
a dart:ffi import.
Change-Id: I9ccaa21099cadb14545c46619b97439623d0415a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/483680
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Nate Biggs <natebiggs@google.com>
Closes https://github.com/dart-lang/sdk/issues/62573
isA<JSExportedDartFunction>() used to just check if the object
was a function, leading to a possible runtime error if `toDart`
is called. Fixes that by introducing some helpers and moving
around some functions in the JS compilers to other internal
libraries (public members can't be added to
js_allow_interop_patch.dart). Also fixes a minor issue in dart2js
where `allowInterop`ed functions could successfully invoke
`JSExportedDartFunction.toDart`.
CoreLibraryReviewExempt: Documentation change.
Change-Id: I5a9d7c31d3143eb3fb6ebd3273a4bf06ca329479
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/482967
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Nate Biggs <natebiggs@google.com>
Fixes https://github.com/dart-lang/sdk/issues/56905
Instead of just supporting isJSAny and isJSObject, we
can support isA for all objects. Depending on the static
type, we include an intrinsic _isJSAny function first in
the transformation. For fast paths for JSObjects, we also
now call an intrinsic function which has the added benefit
of now correctly returning true for objects with no prototype.
The intrinsic functions in dart2wasm need to be careful to
not treat ExternalDartReferences as JS values, so JSValue
is amended to include a field that determines if the value
is a Dart value (and caches it if not set already). JSValue
constructions are updated to pass false for this field if
we know for sure this value isn't an externalized Dart value.
CoreLibraryReviewExempt: Backend-specific function changes.
Change-Id: Ib2a6e74b4130632791375fcda9a5b85198ad64af
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/478241
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
This is one of several planned batches of changes to transition the
front end (and related packages) away from the old `withArgumentsOld`
diagnostic reporting method, and to the new `withArguments`
method. The difference between the two is that `withArguments` has
named parameters rather than positional ones, so (a) it's less likely
for parameters to be mixed up, and (b) it's compatible with the
calling conventions used by analyzer diagnostics.
As part of this transition, I'm taking the opportunity to rename the
parameters themselves (since the names previously were restricted to a
very small set of possibilities based on type), and to document them
in `messages.yaml`. To avoid fatigue (both for myself and code
reviewers), I've chosen to break the change into many smaller batches.
The only changes in this CL that were manually written are those in
`messages.yaml`. The others were produced by running the standard
diagnostic message code generator and then running the script
`use_new_with_arguments.dart`.
Change-Id: I6a6a69642b5d48c3945452b18c4f6aa4ae740245
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/477581
Reviewed-by: Nate Biggs <natebiggs@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This is one of several planned batches of changes to transition the
front end (and related packages) away from the old `withArgumentsOld`
diagnostic reporting method, and to the new `withArguments`
method. The difference between the two is that `withArguments` has
named parameters rather than positional ones, so (a) it's less likely
for parameters to be mixed up, and (b) it's compatible with the
calling conventions used by analyzer diagnostics.
As part of this transition, I'm taking the opportunity to rename the
parameters themselves (since the names previously were restricted to a
very small set of possibilities based on type), and to document them
in `messages.yaml`. To avoid fatigue (both for myself and code
reviewers), I've chosen to break the change into many smaller batches.
The only changes in this CL that were manually written are those in
`messages.yaml`. The others were produced by running the standard
diagnostic message code generator and then running the script
`use_new_with_arguments.dart`.
Change-Id: I6a6a696401eb6ed78954b4aefc25f17b4a3464de
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/477320
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Nate Biggs <natebiggs@google.com>
This is one of several planned batches of changes to transition the
front end (and related packages) away from the old `withArgumentsOld`
diagnostic reporting method, and to the new `withArguments`
method. The difference between the two is that `withArguments` has
named parameters rather than positional ones, so (a) it's less likely
for parameters to be mixed up, and (b) it's compatible with the
calling conventions used by analyzer diagnostics.
As part of this transition, I'm taking the opportunity to rename the
parameters themselves (since the names previously were restricted to a
very small set of possibilities based on type), and to document them
in `messages.yaml`. To avoid fatigue (both for myself and code
reviewers), I've chosen to break the change into many smaller batches.
The only changes in this CL that were manually written are those in
`messages.yaml`. The others were produced by running the standard
diagnostic message code generator and then running the script
`use_new_with_arguments.dart`.
Change-Id: I6a6a6964e05d24e13182f9e8ea37c8e1ec765edd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/477580
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Nate Biggs <natebiggs@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This is one of several planned batches of changes to transition the
front end (and related packages) away from the old `withArgumentsOld`
diagnostic reporting method, and to the new `withArguments`
method. The difference between the two is that `withArguments` has
named parameters rather than positional ones, so (a) it's less likely
for parameters to be mixed up, and (b) it's compatible with the
calling conventions used by analyzer diagnostics.
As part of this transition, I'm taking the opportunity to rename the
parameters themselves (since the names previously were restricted to a
very small set of possibilities based on type), and to document them
in `messages.yaml`. To avoid fatigue (both for myself and code
reviewers), I've chosen to break the change into many smaller batches.
The only changes in this CL that were manually written are those in
`messages.yaml`. The others were produced by running the standard
diagnostic message code generator and then running the script
`use_new_with_arguments.dart`.
Change-Id: I6a6a6964617afe89a9088abde1fbf713281991ef
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/477640
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Nate Biggs <natebiggs@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Translates the code in the following packages:
- `_fe_analyzer_shared`
- `_js_interop_checks`
- `dart2wasm`
- `front_end`
- `vm`
so that it imports diagnostic codes from
`package:front_end/src/codes/diagnostic.dart` or
`package:_fe_analyzer_shared/src/messages/diagnostic.dart`, using the
prefix `diag`, rather than using the old constant declarations in
`package:front_end/src/codes/cfe_codes.dart` and
`package:_fe_analyzer_shared/src/messages/codes.dart`.
This CL was created by the following steps:
- Run the script
`pkg/analyzer_utilities/tool/messages/use_prefixed_import_instead_of_code.dart`.
- Execute `dart fix --apply --code=unused_import,unnecessary_import`
on each of the above package directories (this removes imports that
are no longer necessary due to the change).
- Add `diag` to `pkg/front_end/test/spell_checking_list_code.txt`.
- Use `dart format` to fix formatting errors left behind by
`use_prefixed_import_instead_of_code.dart`.
Change-Id: I6a6a69645d7659259db1acce35c8ee3bb6e347c9
Tested: standard trybots
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/475929
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Liam Appelbe <liama@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Since that stops `dart:_js_annotations` from building on dart2wasm,
let's stop supporting that, too.
This causes `package:js` to no longer work on dart2wasm, but none of the
allowlisted packages use it any longer, so we can simply migrate tests
off of it.
Fixes: #56502Fixes: #61550
Change-Id: I6a6a696438255ebf25a5a17131cdbd327ba81581
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/453645
Commit-Queue: Mayank Patke <fishythefish@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Nate Biggs <natebiggs@google.com>
We'd like to remove `dart:js_util` support from dart2wasm. However,
`dart:js_interop` re-exports some annotation classes from
`dart:_js_annotations`, which exports some members from `dart:js_util`.
To break the dependency chain, we can instead move those classes into
`dart:js_interop` and re-export them from `dart:_js_annotations`.
Bug: #61550
CoreLibraryReviewExempt: code motion, no semantic/API change
Change-Id: I6a6a696451cc1b968062317957fc7883b2242c4a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/453647
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Changes `pkg/front_end/tool/generate_messages_lib.dart` so that only
shared and "pseudoShared" messages are generated to
`pkg/_fe_analyzer_shared/lib/src/messages/codes_generated.dart`. The
remaining front end messages are generated to
`pkg/front_end/lib/src/codes/cfe_codes_generated.dart`.
Previously, a heuristic was used to try to guess which messages
*might* be sharable, which resulted in a lot of messages being put in
`pkg/_fe_analyzer_shared/lib/src/messages/codes_generated.dart` that
were not actually shared.
This change paves the way for sharing more messages between the
analyzer and CFE, by making it clear which messages are shared and
which ones aren't.
A few import statements had to be adjusted as part of this change, to
account for the fact that a lot of generated code was moved.
Change-Id: I6a6a69641fdc79dcf92f25c980c5a0de9196be4c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/449608
Reviewed-by: Ömer Ağacan <omersa@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Fixes https://github.com/dart-lang/sdk/issues/61411
This was previously disallowed for static members in pkg:js
classes, but an error was never added for dart:js_interop types.
We could add an error, but this is useful for both static and
non-static members so users don't have to introduce new top-levels
or types just to access a nested member. This also makes it
consistent with dart2wasm.
Updates some front_end expectations tests as well to test
more syntax and renamed members.
Change-Id: I690d53d64fedc5869e1bdd9f7cfd86d256d7f75b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/447482
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
This is the beginning of a series of CLs intended to change the CFE's
`withArguments` methods (used for diagnostic reporting) so that they
accept named parameters rather than positional parameters. This change
will carry two major benefits:
- It will reduce the risk of mistakes when reporting diagnostics.
- It will make the analyzer and CFE diagnostic reporting mechanisms
more similar, paving the way for sharing more diagnostic reporting
code in the future.
As a first step, this CL renames the old `withArguments` methods to
`withArgumentsOld` and updates call sites. In follow-up CLs, I will
introduce new `withArguments` methods that accept named arguments, and
migrate call sites to use them.
Change-Id: I6a6a6964f4130cdb732b14d515e0ad8f2b65dc26
Tested: standard trybots
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/447625
Reviewed-by: Stephen Adams <sra@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Fixes https://github.com/dart-lang/sdk/issues/60644
Previously, we made no special case for JSBoxedDartObjects, so isA
would always return true for any object (as JSBoxedDartObject contains
an @JS('Object') annotation). This is not obvious however, and it's
much more useful to check that the value is a result of a previous
`toJSBox` call. Documentation is updated/cleaned up to make note of
the various exceptions in `isA`.
CoreLibraryReviewExempt: Web-only library.
Change-Id: Ibd8873d3f862f4c950101f5f049327a1aa5c7bf2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/445522
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
This is part of a series of CLs that will standardize CFE error
reporting to always use `codeFoo.withArguments(...)` when reporting
errors that take arguments and `codeFoo` when reporting errors that
don't take arguments, rather than `templateFoo.withArguments(...)`
when reporting errors that take arguments and `messageFoo` when
reporting errors that don't take arguments. This change will have two
advantages:
- It will lend greater consistency to the CFE codebase, by allowing
the same `code...` objects to be used both to name error codes
(e.g., in test expectations) and to report errors. This will allow
everything associated with a certain error code to be found using a
single invocation of "Find References" in the editor, rather than
having to search separately for uses of the code and the message or
template.
- It should hopefully make the experience of writing code that reports
errors more pleasant, since it will no longer be necessary to look
up an error to see whether it takes arguments before using it;
instead, the developer will be able to type the name of the message
`code...` declaration, and then use autocompletion to see whether
`.withArguments(...)` is required.
In this CL, references to the `message...` declarations that define
errors are changed to the equivalent `code...` declarations. There is
no functional change, since these declarations denote the same
constant object. In a follow-up CL, the `message...` declarations will
be removed.
Tested: standard trybots
Change-Id: I44d4b3cffb768b908d4341a7851f270db6caa87b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/443183
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jackson Gardner <jacksongardner@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This is part of a series of CLs that will standardize CFE error
reporting to always use `codeFoo.withArguments(...)` when reporting
errors that take arguments and `codeFoo` when reporting errors that
don't take arguments, rather than `templateFoo.withArguments(...)`
when reporting errors that take arguments and `messageFoo` when
reporting errors that don't take arguments. This change will have two
advantages:
- It will lend greater consistency to the CFE codebase, by allowing
the same `code...` objects to be used both to name error codes
(e.g., in test expectations) and to report errors. This will allow
everything associated with a certain error code to be found using a
single invocation of "Find References" in the editor, rather than
having to search separately for uses of the code and the message or
template.
- It should hopefully make the experience of writing code that reports
errors more pleasant, since it will no longer be necessary to look
up an error to see whether it takes arguments before using it;
instead, the developer will be able to type the name of the message
`code...` declaration, and then use autocompletion to see whether
`.withArguments(...)` is required.
In this CL, the references to the `template...` declarations that
define errors are changed to the equivalent `code...`
declarations. There is no functional change, since these declarations
denote the same constant object. In follow-up CLs, the `template...`
declarations will be removed, and then a similar set of changes will
be made to replace references to `message...` declarations with
references to the corresponding `code...` declaration.
Tested: normal trybots
Change-Id: I178bd2072349088f342bc39cfc789bcb5c7ef19e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/442732
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Derek Xu <derekx@google.com>
The analyzer already has an enum with the same name, but a slightly
different declaration. (The analyzer's enum declares only severities
of `error`, `warning`, and `info`, whereas the CFE's enum also
declares severities of `context`, `ignored`, and `internalProblem`).
I'm currently embarking on an arc of work that I hope will eventually
culminate in unifying the analyzer and CFE diagnostic message
representations (and their severities) into a single set of
classes. Until that unification is complete, both representations will
have to co-exist in the `_fe_analyzer_shared` package. To reduce
confusion during that time period, I would like the classes to have
distinct names.
Since the analyzer's `Severity` enum is exposed through the analyzer
public API, analyzer clients may depend on the name. So it makes sense
to rename the CFE's `Severity` enum.
Tested: standard trybots
Change-Id: I95622950f49b1754267e441e4636e046045629bb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/442102
Reviewed-by: Liam Appelbe <liama@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Fixes https://github.com/dart-lang/sdk/issues/61085
If a member that is not exportable is marked for export, we
mark it as an error using the member's name. In the case of
unnamed members, however, we don't have a name, and therefore
the template throws an error as it doesn't have a valid arg.
Instead, use "<unnamed>" in the absence of a name.
Change-Id: Ie0776c95f775eb3f09f582d0386a2097beedc7fe
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/439641
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Auto-Submit: Srujan Gaddam <srujzs@google.com>
Under the hood, there is no difference between
`isSubtypeWhenUsingNullabilities` and
`isSubtypeWhenIgnoringNullabilities` by now. This CL makes the
corresponding renames and removals in the CFE and its clients.
TEST=existing
Change-Id: I22060c29834179c30ba62562aa254146b1d7530d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/433480
Reviewed-by: Ömer Ağacan <omersa@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
In order to support dart2js pragma annotations on external js_interop
methods, add the ability to generate stubs for getters, setters and
methods. Create stubs for dart2js only when the method has annotations.
Methods can only be handled by stubs when there are a fixed number of
positional arguments,
Move from using a `builder` to using a slightly more general
'treatement' that can also replace the Procedure's function body.
Issue: #60746
Change-Id: I7482f09d430448001d712dd4645d23f78910920d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/429203
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
This updates the dynamic module compile to emit an extra mjs file containing JS-defined functions and values (i.e. Strings). The runtime then loads this JS module along with the wasm module and links the two.
Change-Id: Iedddf378822f3abd957f0ca9016a9f7883854973
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/422341
Reviewed-by: Ömer Ağacan <omersa@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
The advantages of this approach:
- Annotations on the original getter are preserved, allowing any dart2js `@pragma` to be honored.
- An optimizing compiler (or user via a pragma) can decide to inline or not inline the getter, giving more control over code size.
Change-Id: I719b41640b75634fe00f6b87f95ebca1801cd159
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/418880
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
This is a reland of commit b9b77058a9
Original change's description:
> Migrate to use pub workspace
>
> Use `pub get` to generate `.dart_tool/package_config.json` on gclient sync.
>
> All pkg/ (and a few third_party) packages that are developed inside the sdk repo are included in the workspace from the root `pubspec.yaml`.
>
> All dependencies that are pulled in via DEPS are added as path dependencies via `dependency_overrides` in the root `pubspec.yaml`.
>
> Bug: https://github.com/dart-lang/sdk/issues/56220
> Change-Id: I38c12b608c68da54c57821116cf9aa6696936746
> Tested: relies on CQ of existing tests. Should have no effect on functionality
> CoreLibraryReviewExempt: only core library change is adding a `// ignore:` comment. Should have no influence on functionality
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/397164
> Commit-Queue: Sigurd Meldgaard <sigurdm@google.com>
> Reviewed-by: Alexander Thomas <athom@google.com>
Bug: https://github.com/dart-lang/sdk/issues/56220
Change-Id: I29afabade2d2447dea05121cb87ff50bb21a4b76
Cq-Include-Trybots: luci.dart.try:flutter-linux-try,flutter-web-try
Tested: relies on CQ of existing tests. Should have no effect on functionality
CoreLibraryReviewExempt: only core library change is adding a `//
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/415561
Commit-Queue: Sigurd Meldgaard <sigurdm@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
This reverts commit b9b77058a9.
Revert "Add missing sample pubspec to workspace"
This reverts commit 892ea15ac7.
These seem to break the engine.
Change-Id: Ieee26deb7928c3869a1b6265326c3ce568ffe731
Tested: this is a revert.
CoreLibraryReviewExempt: this is a revert
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/415582
Commit-Queue: Sigurd Meldgaard <sigurdm@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
Use `pub get` to generate `.dart_tool/package_config.json` on gclient sync.
All pkg/ (and a few third_party) packages that are developed inside the sdk repo are included in the workspace from the root `pubspec.yaml`.
All dependencies that are pulled in via DEPS are added as path dependencies via `dependency_overrides` in the root `pubspec.yaml`.
Bug: https://github.com/dart-lang/sdk/issues/56220
Change-Id: I38c12b608c68da54c57821116cf9aa6696936746
Tested: relies on CQ of existing tests. Should have no effect on functionality
CoreLibraryReviewExempt: only core library change is adding a `// ignore:` comment. Should have no influence on functionality
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/397164
Commit-Queue: Sigurd Meldgaard <sigurdm@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
ExtensionTypeMemberDescriptor.memberReference and
ExtensionMemberDescriptor.memberReference are now nullable.
TFA-based tree shaker can now set them to null when extension type
member is not used and removed but corresponding lowered tear-off is
still used and retained.
Front-end never sets them to null and requires non-null memberReferences
when consuming kernel.
TEST=pkg/vm/testcases/transformations/type_flow/transformer/regress_flutter155624.dart
Fixes https://github.com/flutter/flutter/issues/155624
Change-Id: I71f98c02f4659ff72a8c1d7fc6c578e8b8e26d82
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/401382
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
This change removes the implementation of `dart:js` for dart2wasm. The
code is no longer in use and the compiler already provides a static
error if you import `dart:js` internally.
By removing the implementation from the libraries.json spec, we also
show this as unaccessible on conditional imports. This will allow
developers to distinguish JS and Wasm backends
This adapts the original implementation in
https://dart-review.googlesource.com/c/sdk/+/368642 with a few small
changes, but keeps around the existing allowances on `package:js`. Those
can be addressed separately to reduce the disruption from this change.
Closes#55266.
Change-Id: I0d01a424f2fdb4f48879bd1a41c847a92439e74a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/380583
Reviewed-by: Ömer Ağacan <omersa@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Martin Kustermann