Since variable descriptors are generated lazily, printing disassembly
could trigger re-parsing. This should not hurt in general, but running with
--disassemble should not invoke the parser just for printing -- hereby triggering GC or otherwise altering the execution in unexpected ways.
BUG=#26441
R=rmacnak@google.com
Review URL: https://codereview.chromium.org/2133443002 .
The updates to tests/language/generic_local_functions_test.dart use a
local function type argument in its return type, which had not been
tested and did not work.
After a bunch of attempts to change the order in which the resolution
is performed, it suddenly turned out that the offending statement
`visit(node.returnType)` in `ResolverVisitor.visitFunctionExpression`
might be redundant! (.. a subsequent re-resolution in
`ResolverVisitor.analyze` performs the same job, and uses the correct
scope).
So this CL simply removes that `visit..` statement, and the resulting
`dart2js` passes all tests.
Adresses issue https://github.com/dart-lang/sdk/issues/26805.
R=johnniwinther@google.com
Review URL: https://codereview.chromium.org/2128243002 .
The solves the handling of redirecting factories that redirects to other
redirecting factories whos immediate redirection target is unresolved.
For instance
class C {
factory C.a() = C.b;
factory C.b() = Unresolved;
}
The implementation normalizes the properties 'immediateRedirectionTarget',
'redirectionDeferredPrefix', 'effectiveTarget', 'effectiveTargetType', and
'isEffectiveTargetMalformed' by always storing the information on the
implementation element.
R=het@google.com
Review URL: https://codereview.chromium.org/2125823002 .
In order to make an implementation of initializing formal access in
`dart2js` available as specified in issue #26655 now, this CL changes
the scope management such that initializing formals are not in scope in
the constructor body, only in the initializer list.
This is done by introducing a new notion of scopes implemented
by `ExtensionScope`: Such a scope will extend an existing
`NestedScope` rather than adding a new nested scope to it.
R=johnniwinther@google.com
Review URL: https://codereview.chromium.org/2059883002 .
When parsing a field initializer expression or mixin fields,
the current_class must be the mixin application class, not the
mixin class. This is necessary so that type arguments are
resolved in the correct scope class.
Dart2js fails the new regression test language/regress_18713.
Filed issue #26743.
BUG=18713
R=regis@google.com
Review URL: https://codereview.chromium.org/2085003002 .
This CL should fix the problem that arose with commit
543a51ff3e. Here's the description from
that CL:
This CL adds tests for previously uncovered elements of the semantics
and includes fixes such that the desired behavior is obtained. In
particular, an `isInitializingFormal` element may now occur in contexts
where it wasn't expected until now, and changes were made to handle it.
It is also checked that a capture of an initializing formal (in a
function literal) captures the parameter, not the field.
R=johnniwinther@google.com
Review URL: https://codereview.chromium.org/2042293002 .
This CL adds tests for previously uncovered elements of the semantics
and includes fixes such that the desired behavior is obtained. In
particular, an `isInitializingFormal` element may now occur in contexts
where it wasn't expected until now, and changes were made to handle it.
It is also checked that a capture of an initializing formal (in a
function literal) captures the parameter, not the field.
R=johnniwinther@google.com
Review URL: https://codereview.chromium.org/2039833002 .
This CL is an adjusted version of CL 2025853002, adding updates to
`InitializingFormalElementZ` to match the updates applied to
`InitializingFormalElementX`, and adding the new option to the
`MessageKind.DUPLICATE_DEFINITION` example.
Description from 2025853002:
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/2029003002 .
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 .
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 .
This reverts commit 4dca5d0e01.
It seems to cause at least one additional test failure:
Repro:
python tools/test.py -mrelease -asimarm64 --write-debug-log --write-test-outcome-log --copy-coredumps -cprecompiler -rdart_precompiled --exclude-suite pkg -t480 language/async_star_regression_fisk_test
BUG=
R=vegorov@google.com
Review URL: https://codereview.chromium.org/2004373004 .
Third attempt. A latent bug in finally block inlining
caused the previous crashes in optimized functions.
Fix is in https://codereview.chromium.org/2004883004/.
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/2008043002 .
This CL has the same purpose as 1969753002, stated in the title line,
but it works for checked mode execution (where 1969753002 was broken),
and for usage of method type arguments in additional situations.
Approach: `DartType` and subtypes have been extended with new methods
to erase `MethodTypeVariableType` to `DynamicType`. This is done early
(after resolution, before SsaBuilder), such that only few parts of the
compiler need to deal with anything new. This approach handles method
type variables in checked mode, in `new` expressions, and in function
typed parameters. Finally, tests are added for the new cases, and
status files updated.
UPDATE: See message #10 and #12 for an updated description of the approach.
R=johnniwinther@google.com
Review URL: https://codereview.chromium.org/1976213002 .
Second attempt, this time also capturing hidden variables
like 'this' in initializer lists. Original CL is
https://codereview.chromium.org/1980193002
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/1986393002 .
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.
No wall-time improvement found when running dart2js, though.
BUG=26453
R=regis@google.com
Review URL: https://codereview.chromium.org/1980193002 .
This CL was landed and reverted. The bot failures caused by the first
landing of this CL turned out to be caused by checked mode execution.
This is an adjustment of that CL which marks the relevant tests as
failing. The underlying issue is that the compiler phases after
resolution do not expect to receive method type variables, only class
type variables; that will be addressed in a separate CL.
R=floitsch@google.com, johnniwinther@google.com
Review URL: https://codereview.chromium.org/1963703003 .
This CL adds a `DartOptions` comment to the '--generic-method-syntax'
related tests specifying that option, and changes the entries for these
tests in status files to expect success for dart2js except when running
in a browser (where the option gets dropped rather than passed on to
the compiler).
BUG=
R=floitsch@google.com
Review URL: https://codereview.chromium.org/1962633002 .
The new test is specifically for `dart2js --generic-method-syntax ..`,
executed programmatically using 'memory_compiler.dart'.
It verifies that each method type variable is treated as if it had
been an alias for `dynamic` (so the static analysis allows almost
all usages of these type variables, silently). Note that this behavior
is unlikely to be available with any other tools, and even `dart2js`
will behave differently when generic methods are implemented fully.
Hence, the new test will only be useful as-is during a transitional
period.
R=johnniwinther@google.com
Review URL: https://codereview.chromium.org/1939053002 .
Florian Schneider