This is work in progress, I will clean up and document code before
committing. But I'd like to know your opinion before moving forward.
The new top-level inference rules don't allow using instance fields
to perform type inference. So, we need to make this change.
R=brianwilkerson@google.com, paulberry@google.com
BUG=
Review-Url: https://codereview.chromium.org/2754423002 .
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 CL moves many of the files from
pkg/front_end/lib/src/fasta/analyzer/ to pkg/analyzer/lib/src/fasta/.
It also moves two files from pkg/kernel/lib/analyzer/ to
pkg/analyzer/lib/src/kernel/.
This reduces the amount of circularity between analyzer and
front_end/kernel so that there are no files in front_end or kernel
which are both dependend upon by analyzer and depend upon analyzer. I
will clean up the remaining circularities in future CLs.
There should be no functional change.
R=ahe@google.com, asgerf@google.com, kmillikin@google.com, scheglov@google.com, sigmund@google.com
Review-Url: https://codereview.chromium.org/2756593004 .
These utilities are needed for generating the code that supports
summaries; in order to move summary logic into front_end, we will need
these code generation tools in front_end as well.
Also make a minor change to summary code generation logic so that it
talks to the file system directly rather than depending on analyzer's
file system abstraction.
R=brianwilkerson@google.com
Review-Url: https://codereview.chromium.org/2742333005 .
Mostly just making private methods public. But also add in some hooks
(via streams and callbacks) that allow the angular analyzer to wrap
analysis drivers in new angular drivers.
This code will likely all be reverted at some point when a much much
better plugin API is available.
BUG=
R=brianwilkerson@google.com
Review-Url: https://codereview.chromium.org/2742343006 .
In DDC, if the receiver is typed and the target method simply forwards to a JS call, invoke that call directly instead of via a symbol.
This is a step toward #28307.
Paul: can you look the the analyzer / summary code change?
dart:html uses "native". other libraries (e.g., typed_data) use "external" for more or less the same thing. The analyzer element model doesn't provide a way to test for "native" methods, but it does for "external". I map native to external here. Not sure if it's better to treat them as separate (I believe native predated external). Longer term, it may make sense to try to remove "native" in favor of "external".
R=brianwilkerson@google.com, jacobr@google.com, jmesserly@google.com, paulberry@google.com
Review-Url: https://codereview.chromium.org/2748713002 .
This adds an option to enable or disable (enabled by default)
package contributed default analysis options.
If an analysis options file is not explicitly specified
via the "--options" option and an analysis options file
cannot be found in the project directory or any parent directory,
then look for analysis options in the following locations
if this new option is enabled:
- package:flutter/analysis_options_user.yaml
- package:dart.analysis_options/default.yaml
R=brianwilkerson@google.com
Review-Url: https://codereview.chromium.org/2745653012 .
The errors will be associated with inference targets - top-level
variables, static class fields, instance class fields, overriding
instance method parameters with conflicting type in overridden members,
etc.
These errors will be accessible through corresponding Element(s) and
reported by LibraryAnalyzer, and so AnalysisDriver to the client. So,
we will not need to compute these errors once again in ErrorVerifier.
R=brianwilkerson@google.com, paulberry@google.com
BUG=
Review-Url: https://codereview.chromium.org/2736383005 .
The code is still a work in progress, so its test is marked as failing.
Note: I believe there is code duplicatoin between the StackListener
class introduced by this CL and the StackListener class in
pkg/front_end. Once more tests are passing, I intend to remove this
code duplication.
R=sigmund@google.com
Review-Url: https://codereview.chromium.org/2738273002 .
With this change, if the dartanalyzer --verbose option is specified
then you will see additional output indicating which analysis options
file was read:
Loaded analysis options from /path/to/.analysis_options
In addition, if there are any command line flags that specify/override
an analysis option then you will see something similar to this:
Analysis options: strong = true
R=brianwilkerson@google.com
Review-Url: https://codereview.chromium.org/2726783002 .
Konstantin Shcheglov