The behavioral difference is that named and optional arguments are filled in
with their default values in the `Invocation` object passed to `noSuchMethod`.
On the implementation side we make NSM forwarders concrete and fill in their
bodies in the CFE. The custom (and somewhat hacky) VM support is no longer
needed, and Dart2JS can benefit from this implementation as well.
According to discussion on #33031 we will be able to re-land this soon without
breaking Mockito.
Prior failures on precompiler bots are fixed in Patchset 2.
Change-Id: If1b7fe4cf6da5ef38f330e1ad226121bcfc958a1
Reviewed-on: https://dart-review.googlesource.com/54401
Commit-Queue: Samir Jindel <sjindel@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
This reverts commit 7d5025e814.
Reason for revert: <INSERT REASONING HERE>
Original change's description:
> Fix incorrect handling of NSM forwarders and pull all logic into CFE.
>
> The original implementation was designed around a shared misunderstanding
> of optional parameter handling in the spec. (which was also ambiguous about type parameters).
>
> The correct behavior for optional/type parameters is to fill them in with their default values/bounds.
> This behavior can be implemented without any backend support, as is done in this CL.
>
> Change-Id: Ib81f17ead2d2920e755703e244db5afc328d0315
> Reviewed-on: https://dart-review.googlesource.com/52802
> Commit-Queue: Samir Jindel <sjindel@google.com>
> Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
TBR=dmitryas@google.com,sjindel@google.com
Change-Id: Ice6cd36cc62772e013bded83e0f589fe4b5e9d53
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/53400
Reviewed-by: Samir Jindel <sjindel@google.com>
Commit-Queue: Samir Jindel <sjindel@google.com>
The original implementation was designed around a shared misunderstanding
of optional parameter handling in the spec. (which was also ambiguous about type parameters).
The correct behavior for optional/type parameters is to fill them in with their default values/bounds.
This behavior can be implemented without any backend support, as is done in this CL.
Change-Id: Ib81f17ead2d2920e755703e244db5afc328d0315
Reviewed-on: https://dart-review.googlesource.com/52802
Commit-Queue: Samir Jindel <sjindel@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
In order to un-block Flutter integration, we introduce partial support for
conditional imports into the CFE. There are two incomplete parts:
- The condition strings are evaluated by the Target.
They should be looked up in the environment, but this introduces
complications with modular compilation.
- Type inference and other static checks are performed with reference to
the implementation (conditionally-imported) library rather than the
interface library.
See issue #30143 for more details.
Bug:
Change-Id: I740b45e9d32796644837de4caefd8d6e8015f229
Reviewed-on: https://dart-review.googlesource.com/34721
Reviewed-by: Peter von der Ahé <ahe@google.com>
Before: Kernel static errors were represented by throwing a distinguished
error or else by calling a distinguished library const constructor.
Now: Kernel static errors are represented by InvalidExpression. To support
error reporting, InvalidExpression has an optional message and a file
offset. A back end can choose to signal these errors at any time; for
example, when deserializing the binary, or when compiling the procedure
containing the static error, or when the erroneous expression is evaluated
at run time.
InvalidStatement is removed because it can be encoded as ExpressionStatement
of InvalidExpression.
Future work:
* supporting static errors where an expression cannot appear in the AST
* allowing InvalidExpression to contain an Expression for error recovery
* adding a top-level list of static errors and warnings to the binary
Bug: https://github.com/dart-lang/sdk/issues/29840
Change-Id: Ifdfe9a76cee6cefed28061bf245be70531d2f413
Reviewed-on: https://dart-review.googlesource.com/31320
Commit-Queue: Kevin Millikin <kmillikin@google.com>
Reviewed-by: Dan Rubel <danrubel@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Without strong mode, a "good enough" implementation is to simply call
the generic method with "dynamic" for the type arguments, which is what
this does. That should be enough to unblock our internal users.
We also need to not report a compile error when
dart_internal/extract_type_arguments.dart imports the hidden
"dart:_internal" library.
This patch does both of those for the VM and dart2js (using its old
front end).
Note that the test still fails because the test is more particular than
most actual user code would be -- it validates that the instantiated
type arguments are *exactly* correct, and not that the returned object
is merely subtype compatible.
Bug:
Change-Id: I0343beace4991861b29712b3fd7067ec8dc8f8ba
Reviewed-on: https://dart-review.googlesource.com/28020
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
* The package:kernel/transformations/precompiler.dart is moved to
package:vm and split into 2 libraries: metadata/direct_call and
transformations/cha_devrtualization.
* Fasta 'target-options' command line argument and
package:kernel/target/implementation_option.dart are cleaned up
as they are no longer used.
Issue: https://github.com/dart-lang/sdk/issues/30480
Change-Id: I21a7b6bc62a036a9694e62a5dae890f6120d79ab
Reviewed-on: https://dart-review.googlesource.com/26360
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Previously, the front end recovered from an invalid assignment by
producing an "as" expression, e.g.:
int x;
String y;
x = y;
Would produce an "invalid assignment" error, as well as this kernel
code:
int x;
String y;
x = y as{TypeError} int;
The rationale was that the "as" check was guaranteed to fail, so this
code would produce a runtime error at the correct location. However,
there were two problems:
1. (Minor problem) the "as" doesn't actually fail if the RHS is null.
2. (Major problem) for type inference, the type of an assignment
expression is defined to be the type of the RHS. This means that if
the invalid assignment gets used for type inference, we generate
mal-typed kernel code, e.g.:
int x;
String y;
var z = (x = y);
Gets compiled to:
int x;
String y;
String z = (x = y as{TypeError} int);
This CL addresses both problems by changing the kernel representation
so that it evaluates the RHS and then throws an exception. Since a
"throw" expression has type Bottom, the kernel representation is
guaranteed to be properly typed. This also ensures that an exception
gets thrown if the RHS is null. Finally, as a side bonus, it makes
the error-recovered kernel code more similar to the kernel code we
generate in other error recovery scenarios.
Change-Id: Iac74e0c726ce029ac0560d271413e85c15bfec5c
Reviewed-on: https://dart-review.googlesource.com/24140
Reviewed-by: Kevin Millikin <kmillikin@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This CL introduces compileToKernel() function in package:vm/kernel_front_end
as the replacement for kernelForProgram() from package:front_end/kernel_generator.
The new function will be used to customize kernel Programs for VM need.
For example, it will perform additional AOT-specific global transformations.
In future, compileToKernel() will be used from Flutter and precompiler2.
Also, this CL cleans up Target.strongModeSdk as it is no longer used.
Issue: https://github.com/dart-lang/sdk/issues/30480
Change-Id: Ib9c2b5d0af955475292df8e456073a5f0e6a64be
Reviewed-on: https://dart-review.googlesource.com/25080
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
This CL adds handling of previously introduced 'strong-aot'
implementation (target-specific) option into VM target.
After this change, it will be possible to enable strong-mode
whole-program optimizations in Flutter (in addition to standalone VM).
Issue: https://github.com/dart-lang/sdk/issues/30480
Change-Id: I054b75ce4ba1b9bcf150e0b7f25fa7ca1bdd187e
Reviewed-on: https://dart-review.googlesource.com/15644
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
This CL replaces outdated VmTarget and FlutterTarget with VmFastaTarget
and FlutterFastaTarget. 'Fasta' suffix is droped from target names.
The new FlutterTarget extends VmTarget, so they share more code.
Change-Id: Id79956698a889c9a49b8a67914f1f96a731407ab
Reviewed-on: https://dart-review.googlesource.com/9423
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
This CL adds a new target for kernel front-end, vm_precompiler. This is
an experimental target for new Dart VM precompiler pipeline which
will fully exploit strong mode type system and perform whole-program
optimizations.
As an example of such whole-program optimization, this CL adds
draft implementation of devirtualization of method invocations, which
uses single target computed by closed-world class hierarchy analysis.
Corresponding null checks (required for correctness) are not generated
yet.
Issue: https://github.com/dart-lang/sdk/issues/30480
Change-Id: I704cd16843a08f036a188b1188c80ee4dfbeab3b
Reviewed-on: https://dart-review.googlesource.com/3402
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Samir Jindel