The existing support for `ignore` filtering requires the error generator task to depend on parsed sources as input. As it happens, these parse results get flushed between the parse task and error generation, meaning that they need to be recomputed for EVERY source. This change moves ignore detection into the scanner which now produces a new result (akin to LineInfo) that can be used at error generation time (and will not be flushed).
Local profiling shows this change making a roughly 10% improvement to overall analysis time for `flutter analyze`. Server-based analysis should enjoy a similar benefit.
A few thoughts for further refinement:
* can we NOT produce ignore results for sources whose errors we will not generate?
* can we (and should we) improve the regexp-based approach?
BUG=
R=brianwilkerson@google.com, scheglov@google.com
Review URL: https://codereview.chromium.org/2011183004 .
This is not a general fix, but it's a simplest fix I could come up with.
It fixes the common problem of downwards and upwards inference conflicting. On the way down, we use the return context, but on the way back up, we ignore it for `Future.then`. This allows inference to conclude an instantiation like:
f.then/*<Future<int>>*/(...)
Then, thanks to Future flattening, we get the right return type as well (return type is Future<R>, which strong mode interprets as Future< flatten(R) >, so it works out).
Many of the other example cases are not fixed, though. Downwards inference will only push down `R` not `Future<R> | R`, so if the Future<R> branch was needed, for example: Future<Lint<int>> g = f.then(() => new Future.value([])) will not infer the `<int>[]` allocation nor the `Future<List<int>>` type. I have a work-in-progress that fixes those but introduces a special union type notion for `Future<R> | R`, and I'm not sure we're ready for that.
R=leafp@google.com
Review URL: https://codereview.chromium.org/2016793002 .
The non-AST-based type inference engine has the following quirk. With
the source code:
var x = null;
The type of `x` is inferred as `dynamic`, whereas the type of the
synthetic initializer function associated with `x` is inferred as `()
-> <bottom>`.
This CL makes the AST-based type inference engine act in the same way
for consistency.
In the future we may want to change both engines to consistently infer
`dynamic`.
R=scheglov@google.com
Review URL: https://codereview.chromium.org/2014383003 .
To do AST-based type inference involving function closures, we have
added a `bodyExpr` field to UnlinkedExecutable. Since every
UnlinkedParam with a default value has a corresponding
UnlinkedExecutable representing its initializer, it makes sense to
store the constant expression there for uniformity.
R=scheglov@google.com
Review URL: https://codereview.chromium.org/2010993002 .
To do AST-based type inference involving function closures, we will
need to be able to store closure body expressions in unlinked
summaries--this requires adding a `bodyExpr` field to
UnlinkedExecutable. Since every UnlinkedVariable with a body
expression has a corresponding UnlinkedExecutable representing its
initializer, it makes sense to store the constant expression there for
uniformity.
R=scheglov@google.com
Review URL: https://codereview.chromium.org/2013883003 .
A bunch of changes to pave the way for emebdder SDK summary creation.
* Moves _embedder.yaml processing into the embedder SDK (out of the resolver).
* Changes EmbedderUriResolver to compose rather than extend a DartUriResolver.
* Fixes the wierd handling (dropping to add back) of `dart:` URIs.
* Fixes the incorrect overriding docs for `SDKLibraryImpl.shortName`.
* Updates embedder test to include a definition of `dart:core` in anticipation of adding some embedder SDK tests.
Some API work TODO in a follow-up CL (notably the way we check for the presence of embedders by querying the resolver is odd).
BUG=
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org/2009303002 .
It is still pain, but when I try to migrate some implementation
classes to using serialized information it would be nice not to
implement also hasModifier() for every hasX getter.
R=paulberry@google.com
BUG=
Review URL: https://codereview.chromium.org/1979343002 .
pq