The class hierarchy analysis maintains, for each class, a map from raw
supertypes to actual, parameterized supertypes. As an optimization, it
can share these maps between a class and one of its subclasses.
However, the sharing/copying mechanism sometimes ends up with entries
in the map that should not have been there.
This commit removes the optimization and always uses a separate map
for each class.
Closes https://github.com/dart-lang/sdk/issues/31996
Change-Id: I4c641d9c7d15706035791dd2b586a24045afceaa
Reviewed-on: https://dart-review.googlesource.com/39765
Commit-Queue: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Kevin Millikin <kmillikin@google.com>
Implemented more efficient way to iterate ClassSet in class_hierarchy.dart,
ClassSet becomes Iterable<Class>. This considerably improves speed of
ClosedWorldClassHierarchy.getSingleTargetForInterfaceInvocation() and
CHA-based devirtualization.
Time of CHA-based devirtualization on Flutter Gallery reduced
from ~13.4s to ~1.2s.
Also, ClassHierarchy used in devirtualization is configured to ignore
ambiguous supertypes to avoid crashes on Flutter Gallery.
Change-Id: Iaca251ca268aad3d8bb652247650096f19c25839
Reviewed-on: https://dart-review.googlesource.com/38960
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
As requested in #31691 the incremental compiler should be able to
initialize its state from a previously generated dill file.
This CL introduces that functionally.
It is tested, but actual usage (e.g. proper invalidation of old files)
should live outside of the front-end (i.e. it's the callers responsibility).
One option would be for the caller to load the dill file and use the
included sources to invalidate changed files.
On my machine a from-scratch compile of dart2js takes ~5 seconds,
one initialized from such an output and with a single file invalidated
(though it actually hasn't changed) it takes ~1 second and the resulting
dill file is bit-perfect compared to the from-scratch compiled one.
Closes#31691.
Change-Id: I07f5efca5f2684d73f6c252f2dbc2ad04e9b5cd0
Reviewed-on: https://dart-review.googlesource.com/37260
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Kevin Millikin <kmillikin@google.com>
Dart allows 'external' functions which are not connected to their body.
Calling such functions produces runtime error, but they should be accepted
at compile time. Test language_2/external_test verifies this behavior.
This CL fixes treeshaker/findNativeName to return 'null' instead of throwing
an error for 'external' functions without @ExternalName annotation (which
is used to specify native name).
Change-Id: I04ec892af29ffe064ece8fddd6f67c7acdca1139
Reviewed-on: https://dart-review.googlesource.com/37122
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
The front end frequently needs to know whether a procedure is a
"synthetic forwarder", meaning that it is a forwarding stub and *not*
a forwarding semi-stub. This CL provides a getter to compute this,
reducing the risk of front end bugs.
Change-Id: I1a9c584b7843948e7ac256dace25efa99b304bf6
Reviewed-on: https://dart-review.googlesource.com/36900
Commit-Queue: Samir Jindel <sjindel@google.com>
Reviewed-by: Samir Jindel <sjindel@google.com>
It's possible that any type parameter's bound may refer to any other
type parameter. Therefore we need to generate the full substitution
map before trying to substitute any type parameter's bound.
Change-Id: I25bf0b26f4ae2a3896b3437057187acf5081b5ea
Reviewed-on: https://dart-review.googlesource.com/36364
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Commit-Queue: Paul Berry <paulberry@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>
Change Fasta type inference and Kernel type checking to use the new
definition for Future flattening, which is really unwrapping (peeling
off one layer of Future or FutureOr). Use this for inferring types of
`await` expressions and return types from `async` functions.
Ensure that we are using the same notion of flattening for inference
and checking. (Maybe it was a red flag that we weren't.)
This fixes await_test so that it produces a runtime error rather than
a compile time error - see #31541.
A similar change will need to be made to the analyzer - see #31887.
Change-Id: I7d936e9788969a48fdc216628eaa793389fb5e30
Reviewed-on: https://dart-review.googlesource.com/34504
Commit-Queue: Kevin Millikin <kmillikin@google.com>
Reviewed-by: Kevin Millikin <kmillikin@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>
Fixes#31586.
Note that none of the back-ends handle Instantiation nodes yet, so the
language_2 tests added in this CL
(instantiate_tearoff_after_contravariance_check_test,
instantiate_tearoff_of_call_test, and instantiate_tearoff_test) fail
pretty much across the board right now.
Includes two fixes to Instantiation.getStaticType and the kernel type checker:
- Previously, they attempted to perform substitution on the full
function type, which had no effect because the type parameters were
bound.
- The type checker was not checking that type parameter bounds were
satisfied.
Note that the front end doesn't yet check that type parameter bounds
are satisfied by the inferred type parameters. I will address that in
a follow-up CL.
Change-Id: Ib0ad7a5fc5f4a2fdc8c99abe1f2d3d15b21a4974
Reviewed-on: https://dart-review.googlesource.com/29744
Commit-Queue: Paul Berry <paulberry@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>
When the body of a function node in a Procedure is lazy loaded the value
of the Procedures transformerFlags is not properly set before the body
has been read. That means that one can get the wrong result.
This CL makes sure to read the body (thereby setting the correct result)
before answering. The same thing is neccessary when setting the value to
avoid it being overwritten later.
Bug:
Change-Id: Id5e631e69885af0872b9644d02eb7b27dfb13391
Reviewed-on: https://dart-review.googlesource.com/21349
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Kevin Millikin <kmillikin@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>
Also, use more descriptive "redirecting_factory" instead of "factory"
in the textual representation of RedirectingFactoryConstructors.
Bug:
Change-Id: Ib01e21107b86e55a10721dde551e802ef3230c80
Reviewed-on: https://dart-review.googlesource.com/24400
Reviewed-by: Peter von der Ahé <ahe@google.com>
Commit-Queue: Dmitry Stefantsov <dmitryas@google.com>
We change the type of FileUriNode.fileUri from String to Uri, which in principle
doesn't change the binary format. However, we did notice that LibraryParts
weren't serialized as specified in binary.md, so we also fixed that.
Since fileUris are stored as strings in a separate table, Uri.parse is only called
once per unique URI.
Fasta only uses relativizeUri when printing diagnostics, and URIs stored in
expectation files (golden files) are relativized using String.replaceAll.
Change-Id: Ib2dc1b80c03a0cdaf84e48b8b3ba73b16bdf8a40
Reviewed-on: https://dart-review.googlesource.com/25421
Commit-Queue: Peter von der Ahé <ahe@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Aske Simon Christensen