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 .
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 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 .
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 .
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 .
CL https://codereview.chromium.org/1863053003/ added support for most
syntactic constructs in relation to generic methods/functions, and
this one adds the missing ones: Declarations of function typed arguments
with type parameters, declarations of generic local functions, and
declarations of generic literal function expressions. It also adds
support for `super` bounds, because they were discussed recently and
may be quite useful (and it turns out to be no problem to parse them).
Finally, a new test file is added to tests the additional constructs.
BUG=
R=johnniwinther@google.com
Review URL: https://codereview.chromium.org/1878253002 .
This CL adds tests for syntactic support for declaration of type
parameters on methods and named functions, and for passing actual type
parameters in invocations.
The status files declare all the tests to be `CompiletimeError`s
(there is no support for `// AnalyzerOptions=`, so no `--options=..`
can be passed to `dartanalyzer`, even though it does succeed with
`--options=tests/language/X.options` where `X` is the name of the
test).
BUG=
R=brianwilkerson@google.com, leafp@google.com, regis@google.com
Review URL: https://codereview.chromium.org/1779173003 .
The VM now reports the location of the mixin application as well as
the location of the illegal constructor in the mixin class.
Update test language/mixin_illegal_constructor_test to follow the spec.
BUG=
R=rmacnak@google.com
Review URL: https://codereview.chromium.org/1638923002 .
In 451eaab718 the "--supermixin" flag was
removed from the VM and from the shared language tests. This caused
those language tests to fail on analyzer (because analyzer still
requires the flag).
Also some tests that validated the non-supermixin behavior were deleted.
It looks like we are going to keep requiring the flag in analyzer until
the feature is implemented in dart2js (see
https://github.com/dart-lang/sdk/issues/24478#issuecomment-170054303).
So in order to ensure that the analyzer implementation continues to be
tested, we still need the flags in the tests. We also need the old
tests that validate the non-supermixin behavior, since the analyzer
continues to implement that behavior when the "--supermixin" flag is
absent.
This CL does not introduce any new VM failures, because (a) the VM
ignores the "--supermixin" flag, so the tests in which the flag is being
reintroduced will still behave the same way on the VM, and (b) the tests
that validate non-supermixin behavior are disabled on the VM.
R=brianwilkerson@google.com, regis@google.com
Review URL: https://codereview.chromium.org/1635763003 .
Note that we are not pulling in the latest version of analyzer_cli,
since there is additional work to do in analyzer_cli before the pull
request can be merged into master (in particular, lint support needs to
be fixed--see https://github.com/dart-lang/analyzer_cli/pull/67).
Instead we pull in the commit from the pull request itself, which
enables the new task model but makes no other changes.
R=pquitslund@google.com
Review URL: https://codereview.chromium.org/1386233002 .
Lasse R.H. Nielsen