The golden file used by this test includes paths that don't match the
paths emitted during analysis on Windows. After discussion with
Konstantin, Nicholas, and Siggi, we agreed that we don't need to run
this test on Windows.
Change-Id: Ib39b58752c2a5967fde55936c5ca5490bfe94f86
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/135121
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This temporarily:
* sets back to opt-out all libraries in the sdk_nnbd folder until
the migration is further along
* changes the bot to use the check_nnbd_sdk script with a different libraries
file that tracks the migration progress.
Change-Id: I096df232d23e2fb41265b6a51c486fb44f9b228c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/135221
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Joshua Litt <joshualitt@google.com>
This is a reland of 344c584ec4
First attempt failed due to lack of implementation of the new
API from SDK in Flutter/engine that this change introduces.
Fixed by creating dummy implementation in flutter/engine:
https://github.com/flutter/engine/pull/16309
Original change's description:
> Implementation of evaluation to JS in frontend server
>
> - made ProgramCompiler somewhat incremental by letting the user
> set the current library and class
> - fixed a bug in procedure_builder where extension method wrappers
> did not have correct fileEndOffset set, which prevented finding
> dart scope at a line when extension methods are used
> - added new compileExpressionToJs API to frontend server and
> frontend compiler interface
> - added ExpressionCompier class that combines IncrementalCompiler
> and ProgramCompiler to compile expression at given dart location
> to JavaScript
> - in JavascriptBundle, set the module name for library tracking in
> JavaScript and saved program compilers to a table for incremental
> reuse in expression compiler
> - Exposed generator from IncrementalCompiler for use in
> ExpressionCompiler
> - added tests for expression compiler
> - added test for compileExpressionToJs API in frontend server tests
>
>
> Change-Id: Ic5e7829e07030b8ad044da7d35bcf27e9fba81c8
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/132701
> Commit-Queue: Anna Gringauze <annagrin@google.com>
> Reviewed-by: Alexander Aprelev <aam@google.com>
> Reviewed-by: Sigmund Cherem <sigmund@google.com>
> Reviewed-by: Gary Roumanis <grouma@google.com>
> Reviewed-by: Jake Macdonald <jakemac@google.com>
> Reviewed-by: Johnni Winther <johnniwinther@google.com>
Change-Id: I56426d2b6d831b2f8d8c57d468d0b54833a0062e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/134561
Commit-Queue: Anna Gringauze <annagrin@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Optionals were being ignored for some methods and for optionals that
have a default of Undefined or None, they should be marked nullable in
Dart syntax regardless of whether they are in the IDL.
Change-Id: Icc71300dc7d8e06fef640a5ca8d502b093c0580c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/134765
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
This is required when comparing functions type objects with sub-canonicalized functions.
Example:
Function() g() => (() => 0) (opt-out)
Function()? f() => null (opt-in)
both canonicalize their return type as a step in canonicalizing the entire function. Omitting a wrapper around the canonicalized function type (the return value) would result in the runtime types of these functions being canonicalized to the same value.
Change-Id: Icb1fd77458267e769bd4d4f54b71d0f81a323bd8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/133340
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Mark Zhou <markzipan@google.com>
A followup change will delete the patches that are no longer needed once
these changes have been "mirrored" :P to the libraries files in the
flutter repos.
Change-Id: I7d255838b97922198248b29311facd4956001e25
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/134405
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
-Adds field for type nullability for IDL operations
-Adds field for conversions to reflect input and output type nullability
--based on implementation
-Corrects generic object types to include nullability
-Changes 'any' types to dynamics
-Adds nullability to types in various operations
-Converts finals and non-initialized non-nullable fields to getters and
setters
--TODO: convert these to native instead of JS inline
-Modifies nullability for annotations and removes annotations from
setters
Change-Id: Iab19830fd1d7f37b170a4da8672f922c3f9b0863
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/132967
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
The constructor was wrapping the onData handler to hide the type-mismatch. This
copies the same logic to the onData handler.
In non-nnbd code this code was not exercised. The migration of dart:async
made this code reachable on our tests. That's because Stream.first used to
do:
var subscription;
this.listen(() => ... cancel subscription here, ...)
it now avoids making subscription nullable by registering the onData handler
later:
var subscrition = stream.listen(null, ...);
subscription.onData(() => ... cancel subscription here);
This change fixes the following 6 html tests under nnbd:
html/history_test/history/history
html/transferables_test
html/transition_event_test
html/websocket_test
html/worker_test/functional/functional
html/xhr_test
Change-Id: I095ea8d545e65b047504af0367586884bba84d72
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/134120
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
By allowing a transformation to tell if it change dthe structure of a
class we can make sure to update the class hierarchy accordingly,
making sure it's up to date for the next computeDelta call in the
incremental compiler.
Change-Id: Iefed3bb1ecbd17b142266ce4a9e1e477f9d2fc87
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/133222
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This undoes what we did to get the sdk building earlier. Most tests in lib_2
had runtime failures because native elements were not tagged as such.
Besides re-adding dart:html et al to the list of compiled libraries, this ensures
we handle native/extension types properly.
(See #39698)
Change-Id: Ib8516c6d92d12d0f5dccdb5a6cf66e0990b52aff
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/133869
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
- made ProgramCompiler somewhat incremental by letting the user set
the current library and class
- fixed a bug in procedure_builder where extension method wrappers
did not have correct fileEndOffset set, which prevented finding
dart scope at a line when extension methods are used
- added new compileExpressionToJs API to frontend server and
frontend compiler interface
- added ExpressionCompier class that combines IncrementalCompiler
and ProgramCompiler to compile expression at given dart location
to JavaScript
- in JavascriptBundle, set the module name for library tracking in
JavaScript and saved program compilers to a table for incremental
reuse in expression compiler
- Exposed generator from IncrementalCompiler for use in
ExpressionCompiler
- added tests for expression compiler
- added test for compileExpressionToJs API in frontend server tests
Change-Id: Ic5e7829e07030b8ad044da7d35bcf27e9fba81c8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/132701
Commit-Queue: Anna Gringauze <annagrin@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Gary Roumanis <grouma@google.com>
Reviewed-by: Jake Macdonald <jakemac@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
In most cases I provided the type that appeared in the return
statements. For a few test files I explicitly typed the return types as
dynamic because it caused diffs in the expected break point locations
when adding more explicit types and it wasn't totally clear what the
new locations should be.
Change-Id: Ifdd80edcccc5fc4a2083ecdbb0e5fbf1c4453e01
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/133339
Reviewed-by: Nate Bosch <nbosch@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Add a visitor that checks for invalid JS interop usage and reports
diagnostics. Wire the visitor up to the `DevCompilerTarget` and `Dart2jsTarget`.
- Add a message without an analyzer code for this error. In the long term we may
want to also add it to analyzer.
- Add a new package `_js_interop_checks` to share the kernel visitor between
dart2js and ddc. Some of the code is copied from ddc, and in the long term we
can centralize more of the detection of JS interop annotations to this
package.
- Implement the first check to detect definitions of `operator []` or
`operator []=` which are not allowed in JS interop classes.
Change-Id: I095a4b7f4732796dbc3cae55b32d5fc9bcdbd798
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/130733
Commit-Queue: Nate Bosch <nbosch@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Fixes a missing case where DDC allows unwrapped functions to flow to
JavaScript through constructor calls or anonymous object instantiation.
- Pass the `Member` through to `_emitArgumentList` in the case of
constructor calls and object literals so that `isJsInterop` can be
determined.
- Pass an optional `isJsArgument` member through for emitting named
expressions. Previously I thought that no named arguments would be
used for javascript calls, but they are used to create object literals
for anonymous JS types.
- Add both anonymous and non-anonymous constructor invocation examples
to the JS interop test.
Change-Id: I004642f3b2caccc0d8c26786f2bdcb081d135898
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/131462
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Vijay Menon <vsm@google.com>
Commit-Queue: Nate Bosch <nbosch@google.com>
This works on all browsers, in d8, and supports both dartdevk and
dart2js. In the case of dart2js, this also expands minified names and
inlined data.
The result is presented to users as a separate section, so the original
JS stack trace is printed as is, and a second deobfuscated stack trace
is printed afterwards.
Change-Id: I10af5e0241a8c87ad8db48234ce52cfb51a27411
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/132966
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Vijay Menon <vsm@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Also updates StrongComponents to prefer the main component as the root if it is in a cycle. This makes bootstrapping more predictable.
This enables a clean integration of build_runner or ddr (internal) and the frontend_server by allowing it to work with any dev server.
All that is needed is a custom .packages file with `http` uris pointing at a dev server which does all code generation, etc.
Bug: https://github.com/dart-lang/webdev/issues/865
Change-Id: I14533d71e5f7ddac58d98073cf016c2589165e9f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/132962
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Auto-Submit: Jake Macdonald <jakemac@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Konstantin Shcheglov