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 .
There were differences between linux gcc, android gcc,
MacOS clang, and 32 vs. 64-bit w.r.t the __builtin
functions for detecting arithmetic overflow. I couldn't get
them all working at the same time. Instead, I removed them,
and changed to always use the inline assembly. This works
in all the configurations above.
This change also adds a simdbc64 target for building simdbc
for 64-bit, and sets up the android targets. simdbc targets
arm, and simdbc64 targets arm64. You can build them with:
$ ./tools/build.py -m release -a simdbc{64} --os=android runtime
R=iposva@google.com
Review URL: https://codereview.chromium.org/1904153003 .
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 .
Looking up a name x in the library scope or in a prefix can also return
the setter name x=. There were several situations that were not handled
right.
- a getter x and a setter x= should not result in a duplicate name
error (and thus a resolution error at runtime).
- when looking for an untangled name x but a setter x= is found first,
keep looking for x.
BUG=25625
R=regis@google.com
Review URL: https://codereview.chromium.org/1752203002 .
Harry Terkelsen