fixes#27625, Object constraints were not tracked in inference
fixes#27933, pin return type from downwards inference
We now prefer to pick the bound (lower or upper) that had some information on, and it also improves inference error messages somewhat (still a ways to go).
The way this works is we now have a type representing an unknown type: ?. We use ? when performing downward inference steps, instead of `dynamic`. This allows more accurate tracking of type constraints.
For example: given:
var x = await Future.wait([a, b]);
Future.wait<T>'s argument type is Iterable<Future<T>>. Since we didn't know T, we previously pushed down Iterable<Future<dynamic>>. The dynamic caused loss of information. Now we push down Iterable<Future<?>>, allowing us to infer the right type there.
R=leafp@google.com, vsm@google.com
Review-Url: https://codereview.chromium.org/2456803004 .
This implements FutureOr<T> in strong mode, otherwise it's ignored (treated as `dynamic`.
Also fixes strong mode's inference subtype function incorrectly treating `void` as a malformed type. This had the consequence of allowing `void` to be inferred as a type argument.
R=leafp@google.com, paulberry@google.com
Review-Url: https://codereview.chromium.org/2647833002 .
This ensures the runtime type is of the tear-off expression's static
type, even when accessed through a superclass.
I also moved the two tests into a subdirectory so they are easier to
find. (It is inscrutable to me why we would have a single directory
with 1,868 test files in it.) That involved enabling recursive
directory listing in codegen_test, which exposed a couple of things.
Fix#27484.
R=leafp@google.com
Review-Url: https://codereview.chromium.org/2641543003 .
This updates DDC options processing to support:
* --options /path/to/analysis/options/file.yaml
* --enable-strict-call-checks
* --supermixin
* --no-implicit-casts
* --no-implicit-dynamic
As well as general refactoring and cleanup of DDC options processing
R=vsm@google.com
Review-Url: https://codereview.chromium.org/2598593003 .
DDC's codegen test copies those files to a local "gen" directory so
that it can do stuff like splitting out the multitests before it
compiles them to JS.
I left all of that alone, so the rest of DDC's test infrastructure is
unchanged. The very first step that builds the "gen" directory just
copies from sdk/tests/..._strong/... instead and the rest is good to go.
I did not move not_yet_strong_tests.dart somewhere more accessible yet
because I'm not sure if kernel needs it or where it should go.
I did not create any status files because DDC doesn't need them and
there are no test suites for the new directories for the other
platforms.
This should catch tests that suddenly start failing (or passing).
This is an admittedly contrived approach to track compilation failures in
the same runtime logic: the statically failing tests are now compiled
to a trivial output that throws a particular exception. Ideally, we
wouldn't run these, but it's beneficial to keep status in the same
place.
On my laptop, this only adds ~8s to presubmit (which takes ~2:30 min).
Ideas on alternative approaches welcome. :-)
R=jmesserly@google.com, leafp@google.com
Review URL: https://codereview.chromium.org/2079373002 .
The generated summary file matches the generated DDC sdk - i.e., it
does not include dart:io. I modified the codegen_tests to the summary
and had to prune the parts of unittest that relied on dart:io.
Paul / Konstantin: can one of you please look at the summary part?
Bob: can you please look at the unittest changes?
R=rnystrom@google.com, scheglov@google.com
Review URL: https://codereview.chromium.org/1982853002 .
I started trying to get the convert tests all cleaned up and passing
but realized I was going down a rathole. So, for now, all of the slow
or failing ones are just skipped.
BUG=
R=sra@google.com
Review URL: https://codereview.chromium.org/1965563003 .
Partially addresses #504. This is WIP, but wanted your thoughts.
Comment / questions:
- The current js_ast ImportDeclaration assumes a legal identifier I think.
E.g., this gets lowered:
import { src$interfaces } from "matcher"
- Should we thread package root through ModuleCompiler to let it packagify urls?
- How should we handle non-package urls? Pass in an explicit root dir
and go relative?
R=jmesserly@google.com
Review URL: https://codereview.chromium.org/1917863005 .
Highlights
* compile one module at a time
* use summaries to speed up compiles
* use command runner so we can add more commands later
* some long needed renames and file organization
* various other technical debt has been addressed
Lowlights
* lost node.js runner/tests (node output format still supported)
* possibly lost some closure support/workarounds (format still supported)
* needs more end-to-end tests of the new system
R=vsm@google.com
Review URL: https://codereview.chromium.org/1879373004 .
We're hitting a runtime bug on requestAnimationFrame when we compile
against the latest dart:html in the analyzer (45) but run against the
DDC one (based on 39).
Adding the new type name by hand as a workaround until we roll, but
longer term we'll need to compile and run against the same sdk.
R=alanknight@google.com, leafp@google.com
Review URL: https://codereview.chromium.org/1849133003 .
This change removes functionality that is not part of the core Dart Dev
Compiler, in particular those features that were not designed for
incremental/modular compilation.
For a while, the primary way to use DDC will be as a compiler invoked by
a build system, e.g. make or bazel or some node.js based-build system.
We'd love to see the user functionality provided by these return.
In particular, a well designed server+watcher system would be a huge
boost to productivity!
I'll see about moving over HTML reporting to Analyzer CLI. It has a lovely UI.
Thanks to everyone who contributed these features.
The following features were removed:
* DDC transformer. Transformers require whole world, in memory files.
* DDC server. The server has its own mini-build system.
* Various kinds of reporting. These should be moved to Analyzer CLI.
Note: batch compiler and the node runner are left for now.
R=vsm@google.com
Review URL: https://codereview.chromium.org/1788973002 .
Vijay Menon