In f54e667773 I attempted to work around
analyzer flakiness in
co19/Language/Libraries_and_Scripts/Scripts/syntax_t11, but I
accidentally applied the change to
Language/Mixins/Mixin_Application/syntax_t11 instead.
This CL applies the workaround to the correct instance of syntax_t11.
TBR=brianwilkerson@google.com
Review URL: https://codereview.chromium.org/2022343002 .
These tests assert that 'yield*' expressions in non-generator functions
should be a compile-time error. But the spec does not have yield as a
reserved word, so a statement like 'yield* e;' can be interpreted as an
expression statement multiplying the variable 'yield' by e. This is how
dart2js and the VM interpret yield outside of generator functions.
See the discussion in issue #25495R=sigmund@google.com
Review URL: https://codereview.chromium.org/2024203002 .
This CL adjusts the treatment of initializing formals, such that they
can be used in initializers and in constructor bodies. E.g., `x` can be
used as in `C(this.x) : y = x { var z = x + 2; }`.
It hides the new feature under the option '--initializing-formal-access'
which is used in the test 'initializing_formal_access_test.dart'.
It also adds an `example` test to `MessageKind.DUPLICATE_DEFINITION` to
verify that name clashes among initializing formals and other
parameters are detected (which was previously not the case).
Finally, it fixes a typo in a comment, `InitializingFormalParameter` ->
`InitializingFormalElement`.
R=johnniwinther@google.com
Review URL: https://codereview.chromium.org/2025853002 .
Testing should not depend on how long it takes to get a response from the
analysis server.
Depending on how long an analysis step takes, these tests will randomly fail
e.g. when run in -mdebug mode, or with other VM flags that change (i.e. slow-down)
timing (--trace-compiler, --optimization-counter-threshold=5"
There are probably more problematic places like this. I just fixed the ones that
I saw failing when running with --optimization-counter-threshold=5.
BUG=#26556
R=scheglov@google.com
Review URL: https://codereview.chromium.org/2016993004 .
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 .
Fourth(!) attempt. This CL fixes another instance where parsing a nested function modifies the parser state of the function that is being compiled.
When a local function gets compiled the second time, constant
expressions may not be parsed again, since the constant value
is found in the cache. If the expression refers to an outer
variable, it does not get captured correctly.
Fix: instead of parsing a local function repeatedly to capture
outer variables, use the local function’s context scope to mark
outer variables as captured. This fixes the bug, and makes the
compiler more efficient as well.
BUG= 26453
R=rmacnak@google.com
Review URL: https://codereview.chromium.org/2010283004 .
