Reland of https://dart-review.googlesource.com/c/sdk/+/29160
Adds a 'severity' field to diagnostic messages and replaces all
addWarning and addNit functions by a generic addProblem, which uses
the intrinsic severity of the message. Eventually, errors should
also be reported this way.
A special severity value maps into either warning or error for Dart 1
and Dart 2, respectively. Most Dart 1 warnings are in this category.
Fixes some 320 failures of DDK test expecting a compile-time error.
These were previously masked by a workaround in the DDC error handler
which has now been removed.
Closes https://github.com/dart-lang/sdk/issues/31286
Change-Id: Id3b3b7f1fc6a101639fc908c90f3ec7d304a7b4b
Reviewed-on: https://dart-review.googlesource.com/32580
Commit-Queue: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Adds a 'severity' field to diagnostic messages and replaces all
addWarning and addNit functions by a generic addProblem, which uses
the intrinsic severity of the message. Eventually, errors should
also be reported this way.
A special severity value maps into either warning or error for Dart 1
and Dart 2, respectively. Most Dart 1 warnings are in this category.
Fixes some 320 failures of DDK test expecting a compile-time error.
These were previously masked by a workaround in the DDC error handler
which has now been removed.
Closes https://github.com/dart-lang/sdk/issues/31286
Change-Id: I6acea31b8cba7dec8b318e081d28f4eb4ebbf75c
Reviewed-on: https://dart-review.googlesource.com/29160
Commit-Queue: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
* Enable --limit-ints-to-64-bits for CFE when it is used to generate
kernel for VM as CFE relies on int.parse being able to parse correct
literals and reject incorrect.
* Pass --limit-ints-to-64-bits to gen_kernel via environment
variable to support batch mode compilation.
Issue: https://github.com/dart-lang/sdk/issues/31339
Re-landing https://dart-review.googlesource.com/29941 with the fix:
* Use checked-in SDK to avoid timeouts on SIMARM bots.
Checked-in SDK was updated and now includes necessary fixes.
Change-Id: I4a5a99455b60204572f3d619d7eb374035b03e40
Reviewed-on: https://dart-review.googlesource.com/30640
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
* Fixes kernel flow graph builder to use instantiated type argumenst
for CreateArray
* Fixes prologue builder to mask the positon of named arguments in the
arguments descriptor array
* Add a SmiBitAndTOS instruction to DBC
* Implement missing AssertSubtype DBC instruction
* Ensure we don't use field guards in DBC mode
* Remove incorrect assertions in LoadIndexedUnsafe/StoreIndexedUnsafe
* Save argdesc_ in DBC simulator when calling the runtime to optimize
a function (which can call re-entrant to Simulator via const
evalulation)
Issue https://dart-review.googlesource.com/c/sdk/+/29581
Change-Id: Ia14b657db66f90643822b6986ec7f75f746ab0d8
Reviewed-on: https://dart-review.googlesource.com/30340
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
* Enable --limit-ints-to-64-bits for CFE when it is used to generate
kernel for VM as CFE relies on int.parse being able to parse correct
literals and reject incorrect.
* Pass --limit-ints-to-64-bits to gen_kernel via environment
variable to support batch mode compilation.
* Use current Dart SDK instead of checked-in Dart SDK to run CFE
in gen_kernel as checked-in Dart SDK is old and it doesn't have
int.parse fix yet.
Issue: https://github.com/dart-lang/sdk/issues/31339
Change-Id: Iaba2a7945a3faa9427f9aab1e9f2b907fa2246a3
Reviewed-on: https://dart-review.googlesource.com/29941
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
The optimizer uses the "is more specific than" relation to eliminate type tests.
In strong mode, the "is more specific than" relation is supposed to be identical
to the "is subtype of" relation. However, it is not quite true, and this is the
cause of this bug. In non-strong mode (Dart 1), the "is more specific than"
relation uses covariance for both result type and parameter types of functions.
In strong mode, we need covariance of result type and contravariance of
parameter types.
Added regression test and updated status files.
Change-Id: I6315643890db75213af6720aa99d8da7b15f99d6
Bug:
Reviewed-on: https://dart-review.googlesource.com/29900
Reviewed-by: Régis Crelier <regis@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Régis Crelier <regis@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>
The analyzer used to emit a warning when a type parameter to a generic
method was used in an "is" check. This warning was there to help
users write code that worked correctly on both Dart 1.0 and 2.0. Now
that 2.0 generic methods are being more broadly supported and used,
this warning is blocking further library work, and is being removed.
Fixes https://github.com/dart-lang/sdk/issues/30530
Bug:
Change-Id: I70395305ad082aee3072b5beeb0b1b7f7883391b
Reviewed-on: https://dart-review.googlesource.com/29821
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
* CompileStaticInitializer() should check result of Compile()
and should not leave sticky error. If left, this sticky error
could be picked up by compilation of some unrelated static
initializer. Also, assertions are added to make sure that code
which explicitly or implicitly relies on sticky errors is not
getting an error on entry.
* CompileStaticInitializerIgnoreErrors() clears sticky errors to
ignore them.
* Added inline bailout reason for cyclic static fields.
This guards against inlining of code which uses a field into static
initializer. This code might not be called so it should not trigger
compilation error eagerly.
Change-Id: I52da6f4cd05556125fd1a628b665dcc11621a4f7
Reviewed-on: https://dart-review.googlesource.com/28523
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Alexander Markov <alexmarkov@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>
Preliminary testing shows, this increases performance by around 20%. The
main benefit is by re-using a warmed-up VM and not start one from
scratch for every compilation.
Going forward we can do more optimizations, e.g. reading the platform
dill file only once into memory (instead of repeatedly) ...
=> This requires us using the new state-full IKG compiler.
Issue https://github.com/dart-lang/sdk/issues/31585
Change-Id: I2d3448783fc118611baf4671187a897227a65a6c
Reviewed-on: https://dart-review.googlesource.com/28400
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
If a .dill file is specified on the VM command line (dart/dart_bootstrap),
and --kernel-binaries is not specified, then this dill file is used as
the source of platform libraries.
It supports the case of AOT-compiling a self-contained .dill file.
Change-Id: I42956a20b98958b9a2440f156fbbef17bfc359f8
Reviewed-on: https://dart-review.googlesource.com/24341
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
There is no actual implementation here yet (that's your job :) ), but there is:
- An external method in dart:_internal, extractTypeArguments().
- Empty patch methods for that for the VM, dart2js, and DDC. These need to have implementations
filled in.
- A "dart_internal" package to expose a subset of the API. It gives you:
extractListTypeArgument()
extractMapTypeArguments()
We'll bring this into Google, but not publish it externally unless we find we really need to.
- A test for the behavior. It probably has bugs since I can't run it.
See: https://github.com/dart-lang/sdk/issues/31371
Change-Id: I7d9f9a3a36f8e8be106440375c80d584898c83cb
Reviewed-on: https://dart-review.googlesource.com/26467
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Reviewed-by: Vijay Menon <vsm@google.com>
This CL normalizes all status files by the status file normalizer found at
pkg/status_file/bin/normalize.dart.
To make sure all status files are kept in pristine condition, a linter is placed
on the presubmit hook. The linter can be found at pkg/status_file/bin/lint.dart.
Bug:
Change-Id: I20bdb74824be65f079b8c9ab08b7ae38394d637f
Reviewed-on: https://dart-review.googlesource.com/24112
Commit-Queue: Morten Krogh-jespersen <mkroghj@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
This CL fixes type inference of closures using '=>' syntax so that
they infer consistently with an equivalent closure defined using block
syntax ('{}').
Fixes#31436.
Change-Id: I5463dd0ba986e9953ebabbc24ce3ced9a7220007
Reviewed-on: https://dart-review.googlesource.com/27084
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
is of class Future, when test type is FutureOr.
This was missing only when testing an instance, not when testing a type or a
parameterized class.
Change-Id: I1609f6f7df80f15a8f36d18bf504df444dfbb928
Reviewed-on: https://dart-review.googlesource.com/27083
Reviewed-by: Régis Crelier <regis@google.com>
Without this fix, there is a risk that the unknown type ("?") will
leak into kernel code via the "as" expression inserted for an implicit
downcast.
Change-Id: Iea7276c8489eff80fe32f33e53efd42571c94a89
Reviewed-on: https://dart-review.googlesource.com/26861
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
When an implicit cast can be proven by the front end to always fail,
due to the form of the expression being cast, the front end now
reports this as a compile-time error. (This feature is not new--it is
part of the analyzer's implementation of strong mode).
Newly failing tests are marked with issue #31537.
Change-Id: Ib3fc068352bb91dd283fa4b81d8104fa213eafe9
Reviewed-on: https://dart-review.googlesource.com/26420
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Update dartkp status files, since --strong is now properly passed to the runtime.
Change-Id: I36dcc04a70f46730b24b5aaa2f118ed9baf42cbd
Reviewed-on: https://dart-review.googlesource.com/26561
Reviewed-by: Régis Crelier <regis@google.com>
Fixes#21938 (Front end does not warn on function calls on Object).
A small number of tests begin failing with this change--these tests
have been marked with issue #31533 for later triage.
Change-Id: I3a956410a6780772fe90098d8604fb10718504df
Reviewed-on: https://dart-review.googlesource.com/26045
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Paul Berry