If we use `_InvocationMirror._withoutType`, the symbol for the member name is created dynamically and escapes obfuscation.
We need to create the member name symbol statically via a `const` constructor.
Change-Id: I11c0f745187f4ef1646be6d5348780f502393043
Reviewed-on: https://dart-review.googlesource.com/c/81264
Commit-Queue: Samir Jindel <sjindel@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
class in a foreign library.
This CL changes the predicate which is used to decide whether to
generate noSuchMethod forwarders such that it returns true whenever
the class in question has a user defined no such method or the
enclosing library of the class is different from that of the member.
Closes https://github.com/dart-lang/sdk/issues/33727
Change-Id: I0ffcbb8c8bdd69e4261bcefce2251d31babc19cf
Reviewed-on: https://dart-review.googlesource.com/c/79209
Commit-Queue: Daniel Hillerström <hillerstrom@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
The parser now generates a ConstructorWithTypeArguments error and a new
handleInvalidTypeArguments event after a begin/endTypeArguments event pair
when those type arguments are in a syntatically invalid location.
For example: `new C.n<int>();` in
```
class C<T> { T f; C.n() {} }
main() { var x = new C.n<int>(); }
Most listeners handle this event by dropping the invalid type arguments,
but AstBuilder now preserves those invalid type arguments in the AST
to support better code quick-fixes/quick-assists/refactoring.
Change-Id: I5b22bd4903cd9ee3645936b9a108598b603cf9ca
Reviewed-on: https://dart-review.googlesource.com/c/79300
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Dan Rubel <danrubel@google.com>
The CL is reverted because it didn't account for the case when a check
of a user-specified type argument against the bound depends on another
type that is only known after type inference is done.
Change-Id: I1fd140af95ed37b9191a5b161a281d4639e3453f
Reviewed-on: https://dart-review.googlesource.com/c/79048
Commit-Queue: Dmitry Stefantsov <dmitryas@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
The implementation strategy is to replace int literals with double
literals during type inference, provided they occur in a double
context and can be represented exactly as a double. This requires us
to keep integer literals larger than the 64-bit range until after type
inference and to keep the source text of 64-bit integers until after
type inference for error reporting.
We postpone the check for web int literals as well because the
expression generator that was performing it isn't otherwise needed.
Fixes https://github.com/dart-lang/sdk/issues/34357.
Change-Id: Ia78c031565cad83961675fc4fb1cc871eaed01d3
Reviewed-on: https://dart-review.googlesource.com/c/78122
Commit-Queue: Kevin Millikin <kmillikin@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
Demangle all names in messages to avoid printing mangled names in
user-facing output.
Point messages about implicit mixin application classes at the subclass
name for consistency with named mixin application classes.
Change-Id: I90973986c422f271af99e18b3deb5847adf4d430
Reviewed-on: https://dart-review.googlesource.com/c/77380
Reviewed-by: Kevin Millikin <kmillikin@google.com>
The code in class_hierarchy.dart that looped over override pairs
included implementations inherited from its superclass as potential
overriders, presumably in a broken attempt to include some interface
checks into the mix.
With this problem fixed, the special case in kernel_class_builder.dart
that excluded overriders not declared in the current class (i.e.
declared in a mixin) could be removed without incurring false
positives.
These override checks performed on members from a mixin produce an
extra context message indicating the class where the two members meet,
giving rise to the override relation (similarly to interface checks).
Since the same member can now override more than one member (or even
the same member more than once), the diagnostics message duplication
check has been extended to also include the context in the comparison.
Fixes https://github.com/dart-lang/sdk/issues/34235
Fixes https://github.com/dart-lang/sdk/issues/34285
Change-Id: I990e5719ae1749fd1aad1ad478aaa6e173cb170b
Reviewed-on: https://dart-review.googlesource.com/c/76900
Reviewed-by: Daniel Hillerström <hillerstrom@google.com>
When a member in the interface of a non-abstract class is found to
have an implementation with the correct name which does not override
the representative declaration of the member in the interface (and thus
has not been checked against that member for override validity), call
the override check to check interface validity.
Override relations thus checked produce an extra context message
explaining that the override relation must hold because both members
are inherited by a non-abstract class.
Fixes https://github.com/dart-lang/sdk/issues/32014
Change-Id: I955f057e35fa30f33c19da37c9cea1262042431c
Reviewed-on: https://dart-review.googlesource.com/c/74642
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Allow super calls to occur in mixin declarations if they target a
method from any of the superclass constraint interfaces.
Instead of compiling the Dart mixin declaration
mixin M on S0, S1 {...}
to Kernel:
abstract class _M&S0&S1 = S0 with S1;
abstract class M extends _M&S0&S1 { ... }
we compile it to Kernel:
abstract class _M&S0&S1 implements S0, S1 {}
abstract class M extends _M&S0&S1 { ... }
because the former is not symmetrical with respect to S0 and S1. It
will prefer a method from the 'mixin' S1 over one from S0 which can
give a compile-time error if the method from S0 is more general.
Modify mixin inference to support the new compilation of mixin
declarations. It still has to support old-style VM super mixins until
support for those is removed from the VM.
Change-Id: Ib945aa11cc19c457b07bc802beae10d1663ff6b7
Reviewed-on: https://dart-review.googlesource.com/76141
Reviewed-by: Jenny Messerly <jmesserly@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Commit-Queue: Kevin Millikin <kmillikin@google.com>
Prior to this CL the return type of any constructor function was
always void. According to the specification §9.3 the return type of a
constructor function ought to be its enclosing class.
Change-Id: I70d76cc354b7f118ce96bf4954daf7fe535eb7be
Reviewed-on: https://dart-review.googlesource.com/76160
Commit-Queue: Daniel Hillerström <hillerstrom@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
Before, a duplciated declaration would cause the compiler to abort using
deprecated_InputError.
Change-Id: Ide8d13802045e9a349f0f408a6d174a47c7f6418
Reviewed-on: https://dart-review.googlesource.com/76122
Commit-Queue: Peter von der Ahé <ahe@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
In VM, 'new List' is equivalent to either 'new _GrowableList' or
'new _List' depending on the number of arguments.
This change does the transformation early (on kernel AST), in order
to have specialized representation in TFA and in bytecode.
Change-Id: I46f0db8cc19efb3a53fdbe971ac26bdd2736fbda
Reviewed-on: https://dart-review.googlesource.com/76283
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
If there are circular references between type parameters and types in the bounds,
currently serialization leaves original type parameters unchanged, which results
in failures to serialize compiled expression procedure.
This CL makes sure to clone all type parameters first, then passes map
with old-to-new type parameters to CloneVisitor.
Bug: https://github.com/dart-lang/sdk/issues/34052
Change-Id: Idf3e6e6e9099f93cdd7e970ab3b21921cdb29178
Reviewed-on: https://dart-review.googlesource.com/75241
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Alexander Aprelev <aam@google.com>
Peter von der Ahé