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>
Async transformation uses dynamic variables in few places (e.g.
for temporaries and for incomming arguments) - which creates
not strongly typed AST with method invocations having dynamic
receivers and non-null interface targets at the same time.
To maintain strong typedness of the AST we insert unsafeCast
when accessing the temporaries.
Bug: https://github.com/dart-lang/sdk/issues/34463
Change-Id: I11e38c128645ebc8acb0c982a80fe4c5c4036673
Reviewed-on: https://dart-review.googlesource.com/75000
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
The BodyBuilder now operates on TypeBuilders instead of DartType.
This
* enables better error messages, and
* paves the way for removing the dependency on OutlineBuilder from BodyBuilder.
Change-Id: I2fb5e61a4d30c11f01d04cc0150d5352b4fb6999
Reviewed-on: https://dart-review.googlesource.com/74064
Reviewed-by: Jens Johansen <jensj@google.com>
Previously we could get something like this:
```
regress_32660_test_06.dart:9:7: Context: 'foo' is defined here.
class I extends G implements H {
^^^
```
because a SyntheticForwarder was added with a file location of the
class.
It now instead goes to the forwarding stub target and says
```
regress_32660_test_06.dart:6:3: Context: 'foo' is defined here.
foo(int x, {int y}) => y;
^^^
```
Change-Id: I6fb1b958f58635c9afffa8e58cd49eb69df28afd
Reviewed-on: https://dart-review.googlesource.com/72680
Reviewed-by: Peter von der Ahé <ahe@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Implement the feature spec for checking returns against inferred
function return types:
https://github.com/dart-lang/sdk/blob/master/docs/language/informal/invalid_returns.md
with the change that an invalid return without a subexpression is
a warning, not an error. This is because it is a warning in the
analyzer and it would be a breaking change to turn it into an
error.
The check for valid returns is moved to exactly where we handle
returns, rather than in ensureAssignable which is used as a
helper in a lot of places. A bug in type inference was fixed: we
would use `void` for the type of return without a subexpression
instead of `null`. To accommodate that we would use a
non-standard subtyping relation for returns. This could lead to
us inferring a return type of `void` in cases where we should
not.
Change-Id: Iee9ece9c722f47efa305f49490d3022d0bbb9f44
Reviewed-on: https://dart-review.googlesource.com/72403
Commit-Queue: Kevin Millikin <kmillikin@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
E.g. `new Map<String>` is now reported as an error.
Note that this does not add a check for whether correct types are given,
so e.g.
```
class Foo<X extends num> {}
main() {
new Foo<String>();
}
```
is not caught by this fix.
Fixes#32972, #32281.
Change-Id: I57513b5c13865a828890775c8e14f7433d00bdbe
Reviewed-on: https://dart-review.googlesource.com/72382
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
Revert "Store named types resolution during outline building."
This reverts commit 82947cccc9.
Revert "Store reference/type for invalid types."
This reverts commit 9fb6c09015.
Revert "Clear ShadowX references that are not required after compilation."
This reverts commit 6c39bc38f3.
Revert "Store constructor field initializera when the target is not a field."
This reverts commit 12326c10e1.
Revert "Don't rewrite error Severity for special cases of front-end testing."
This reverts commit 4bb3fb6cae.
Revert "Translate ConstructorElement(s) of parameterized InterfaceType(s) to ConstructorMember(s)."
This reverts commit 62a2752b96.
Revert "Store resolution for out of range integer literals."
This reverts commit 8df84c0a00.
Revert "Infer original expression in SyntheticExpressionJudgment."
This reverts commit cec29e4aa8.
Revert "Resolve invalid 'as' constant expression."
This reverts commit 77202bf2b0.
Revert "Resolve invalid return from constructor."
This reverts commit 737e546939.
Revert "Store import prefix offset into metadata and resynthesize."
This reverts commit c30af508a4.
Revert "Get documentation comments before metadata as well."
This reverts commit 29401573d5.
Revert "Put fileEndOffset into ArgumentsJudgment and use to report argument errors."
This reverts commit d69a354026.
Revert "Return SourceSpan with actual length from _CompilationMessage."
This reverts commit ac973e5ba7.
Revert "Store codeOffset / codeLength for classes."
This reverts commit 28583df3ee.
Revert "Store and resynthesize codeOffset/codeLength for functions and methods."
This reverts commit 5a2a13c8bf.
Revert "Fix analyzer/FE integration of invalid assignments to classes."
This reverts commit a814614cf4.
Revert "Fix analyzer/FE integration of assignments to non-l-values."
This reverts commit d10204f3a0.
Revert "Fix analyzer/FE integration of assignments to ambiguous types."
This reverts commit e87efdffb4.
Revert "Fix analyzer/FE integration of assignments to ambiguous types."
This reverts commit 1b5d273fd7.
Revert "Fix analyzer/FE integration of assignment with synthetic LHS."
This reverts commit 55aa031404.
Revert "Revert "Fix analyzer/FE integration of assignments to ambiguous types.""
This reverts commit 9f795883f1.
Revert "Store code range for constructors."
This reverts commit 675b296d49.
Revert "Store codeOffset/length code fields and top-level variables."
This reverts commit 9ef53bde19.
Revert "Re-land "Fix analyzer/FE integration of assignments to ambiguous types.""
This reverts commit 40d72aec8c.
Revert "Resolve metadata for part-of directives."
This reverts commit cf1cd3eba0.
Revert "Fix analyzer/FE integration of assignment with synthetic LHS, inside class method."
This reverts commit 43a8f1d0d6.
Revert "Fix analyzer/FE integration of prefix/postfix increment of non-l-values."
This reverts commit e2aceb692e.
Revert "Fix analyzer/FE integration of postfix-of-postfix and prefix-of-prefix increments."
This reverts commit ad6f89f13b.
Revert "Fix analyzer/FE integration of some obscure invalid assignment cases."
This reverts commit f074f3c120.
Revert "Resolve namespace combinators."
This reverts commit 7e39d07916.
Revert "Fix analyzer/CFE integration of some more obscure invalid assignment cases."
This reverts commit a94e43af7c.
Revert "Refactor duplicate code in ContextAwareGenerator."
This reverts commit 1f82d37124.
Revert "Resolve required arguments after named."
This reverts commit b255f0fab6.
Change-Id: I44616db9b8ef037a2580a1ab35050da7e72ff7d8
Reviewed-on: https://dart-review.googlesource.com/72642
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Peter von der Ahé <ahe@google.com>
When invoking an expression whose static type is not a function type,
signal an error. However, allow invocations of expressions with
static type `dynamic` or `Function`. Fixes#32975.
Change-Id: Ia54d8df650076ad5c9c9c3a2c6f79ea31acbbbfe
Reviewed-on: https://dart-review.googlesource.com/72082
Commit-Queue: Kevin Millikin <kmillikin@google.com>
Reviewed-by: Daniel Hillerström <hillerstrom@google.com>
Bug: https://github.com/dart-lang/sdk/issues/33022
This commit adds an error when a final field is not initialized at all
(and there is at least one generative constructor). A later commit
will add an error for the case where a field is initialized by some,
but not all, generative constructors.
A number of classes in the Dart2js and DDC support libraries use
uninitialized final fields to indicate getters in the corresponding
native classes. This commit adds a temporary whitelist for the
affected files, which can be removed when the fields have been
replaced by external getters.
This is tracked by https://github.com/dart-lang/sdk/issues/33762
Change-Id: I6b5cee230c7cd5554da2b61da7ebddb6b0b9396e
Reviewed-on: https://dart-review.googlesource.com/63781
Reviewed-by: Daniel Hillerström <hillerstrom@google.com>
Before this CL, if initializing from a dill file containing a class,
say A, but it wasn't used, and then later using it as a type, say
'A a = new A()', the class hierarchy would complain about not knowing A.
This was caused by the class hierarchy initially being constructed using
the full component of the first compile (i.e. in the example above
without any usage of A and thus without including A), and subsequent
compiles telling the class hierarchy about new classes created in that
compile. The problem was, that if the class was loaded from a dill file
(in the example above 'A' was such a class) it would never be included
if not a part of the first full component.
This CL fixes it by changing the interface to the class hierarchys
`applyTreeChanges` function and letting the class hierarchy know about
libraries too: It will now basically just be given the full component
when asked to update, and just update with the libraries it doesn't
already know about. In the example above that would - once using 'A' -
include 'A'.
Change-Id: I895100b51659938636da0bca6c80516d87b57a24
Reviewed-on: https://dart-review.googlesource.com/69302
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Dmitry Stefantsov