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>
Previously, mixin deduplication transformation expected that isAnonymousMixin
classes could occur only in a superclass position. After this change,
deduplication also handles (canonicalizes) isAnonymousMixin classes in
implementedTypes, as CFE uses isAnonymousMixin classes in implementedTypes
to represent superclass constraints for mixin declarations.
No other uses of isAnonymousMixin classes supported.
Fixes https://github.com/dart-lang/sdk/issues/34704
Change-Id: I8558ce53c4fb1e5a06f839fa5ec8022958d9dafd
Reviewed-on: https://dart-review.googlesource.com/c/78383
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Auto-Submit: Alexander Markov <alexmarkov@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>
This is a reland of 7419667d67
I reverted this CL in
https://dart-review.googlesource.com/c/sdk/+/77520 because I thought
it had broken a bunch of bots. It turns out that the bots weren't
broken; they were just erroneously reporting a breakage because some
change-detection code had noticed that there were new failing tests,
and there is not yet a way to tell the change-detection code that the
failures are expected.
Original change's description:
> Test that the result of instantiate-to-bounds is appropriately checked for super-boundedness.
>
> When I implemented super-boundedness for the analyzer in
> b1a54154f8, very little test status
> changed, indicating we didn't have much test coverage for verifying
> that the result of instantiate-to-bounds was appropriately checked for
> super-boundedness. This CL fills in the coverage gap.
>
> Change-Id: I8f6fbb3aa4cae1e62861b5eddb113ee9b4bb085c
> Reviewed-on: https://dart-review.googlesource.com/77010
> Commit-Queue: Paul Berry <paulberry@google.com>
> Auto-Submit: Paul Berry <paulberry@google.com>
> Reviewed-by: Erik Ernst <eernst@google.com>
Change-Id: Ic84321e928aaf4c6533e6cf5b9d521a1da77dba7
Reviewed-on: https://dart-review.googlesource.com/c/77660
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This reverts commit 7419667d67.
Reason for revert: Broke a lot of bots. Will investigate tomorrow.
Original change's description:
> Test that the result of instantiate-to-bounds is appropriately checked for super-boundedness.
>
> When I implemented super-boundedness for the analyzer in
> b1a54154f8, very little test status
> changed, indicating we didn't have much test coverage for verifying
> that the result of instantiate-to-bounds was appropriately checked for
> super-boundedness. This CL fills in the coverage gap.
>
> Change-Id: I8f6fbb3aa4cae1e62861b5eddb113ee9b4bb085c
> Reviewed-on: https://dart-review.googlesource.com/77010
> Commit-Queue: Paul Berry <paulberry@google.com>
> Auto-Submit: Paul Berry <paulberry@google.com>
> Reviewed-by: Erik Ernst <eernst@google.com>
TBR=paulberry@google.com,lrn@google.com,leafp@google.com,eernst@google.com
Change-Id: I536c9721a1d79b98b2e3c2a6f7650b134b19f561
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/77520
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
When I implemented super-boundedness for the analyzer in
b1a54154f8, very little test status
changed, indicating we didn't have much test coverage for verifying
that the result of instantiate-to-bounds was appropriately checked for
super-boundedness. This CL fills in the coverage gap.
Change-Id: I8f6fbb3aa4cae1e62861b5eddb113ee9b4bb085c
Reviewed-on: https://dart-review.googlesource.com/77010
Commit-Queue: Paul Berry <paulberry@google.com>
Auto-Submit: Paul Berry <paulberry@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
Other than tests already marked as failing under langauge_2_kernel.status in a [$fasta] section, only 2 tests present runtime failures, which might be a dart2js issue that we should
investigate.
TBR=johnniwinther@google.com
Change-Id: I6a62ec77d0d44335315752208720ab9fe6e1e2bb
Reviewed-on: https://dart-review.googlesource.com/77012
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
I'm trying to fix an analyzer bug where typedef type parameters
weren't checked properly, and it appears that we have no language_2
test cases for it.
Change-Id: I216a337eeaae6ac2008c0c26139797e00099ffcb
Reviewed-on: https://dart-review.googlesource.com/76707
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
Commit-Queue: Paul Berry <paulberry@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>
When I first began working on the feature I mistakenly thought that
these two test cases would be free from compile-time errors, so it
seemed like it would be worth adding a test case to make sure others
don't have the same misunderstanding.
Change-Id: I322991c818f9d136180de443090fa4e15f6f0e27
Reviewed-on: https://dart-review.googlesource.com/76680
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
This change expands typedefs into their underlying function type in the
compiler. Typedefs no longer exist at runtime in DDC, so they now have
similar equality and identity behavior as other function types.
The compiler used to preserve typedefs so they could have a better
toString. But over time that support has been almost entirely lost;
the caching for function/interface types eliminates typedefs, and
DDC+Kernel does not appear to get any TypedefTypes from the common
front end. So in practice typedef types were almost never present at
runtime. Because of this, we can remove the remaining support with very
little user visible effect. This also brings DDC's canonicalization
roughly in line with dart2js for compile-time typedefs, so frameworks
like Angular will be able to continue their use of `identical` for fast
type comparisons.
This CL also fixes DDC's type caching for generic function types
(typeHashCode was incorrect for them), and has some refactoring to
improve names/comments and make the SDK runtime code more clear.
Change-Id: I4e34c0c8f737a8535ba474a4683967ff41bcd3c8
Reviewed-on: https://dart-review.googlesource.com/74664
Commit-Queue: Jenny Messerly <jmesserly@google.com>
Reviewed-by: Alan Knight <alanknight@google.com>
This required adding an implementation of super-bounded types to the
analyzer.
We really could use some more tests to verify that we disallow
super-bounded types in all the appropriate locations, but allow it in
other cases (it seems that there are no language_2 tests to verify
this). To avoid churn, I'll wait until I have confirmation that my
reasoning is correct in #34583 before submitting test cases.
Fixes#34532.
Fixes#34560.
Change-Id: I3c5def60bcac0d31b56bead31cb1aab445f18e96
Reviewed-on: https://dart-review.googlesource.com/76280
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This reverts commit 836a1d7a88.
Revert "Don't use ClassElementImpl for now in override checking."
This reverts commit 58e44c1400.
Revert "large_class_declaration_test is slow now."
This reverts commit 56f6c52d58.
Revert "Add regression test for issue 34392."
This reverts commit ef7d144bc7.
Revert "Mixin declarations don't have supertype, fix isMoreSpecificThan()."
This reverts commit 95b8a19a20.
Change-Id: Icda9cf9091ef35acc8fd61ac5dc135b3717eba0a
Reviewed-on: https://dart-review.googlesource.com/76301
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Zach Anderson <zra@google.com>
- option --no-preview-dart-2 will now result in an error
- change aot-assembly build rule to generate AOT snapshot using Dart 2
- generate coresnapshot using Dart 2 (this snapshot is not used yet, next CL which switch the isolate create code to use this snapshot)
- by pass all Dart1 test runs in the status file
- change the default compiler setting in test.py to use dartk
- have test.py not pick up any configuration for --no-preview-dart-2
Change-Id: Ia136943ebfd0fed0c52683b330745b3e2c7a7ce6
Reviewed-on: https://dart-review.googlesource.com/75820
Reviewed-by: Zach Anderson <zra@google.com>
Commit-Queue: Siva Annamalai <asiva@google.com>
If a field is initialized with null (either explicitly or implicitly),
field store can be omitted in bytecode. In such case, bytecode should
still convey the information about this initialization to VM for
field guards to work correctly.
Change-Id: I1fd45b858c3c521b97fa5dbffe0e15b1ea75d92f
Reviewed-on: https://dart-review.googlesource.com/76060
Reviewed-by: Zach Anderson <zra@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
Test mixin class definition syntax, and test that inference is not
performed in the on clause of a mixin. Bug fixes.
Change-Id: I01679c4eb556d9c7bd9227b5d3a79293a027706c
Reviewed-on: https://dart-review.googlesource.com/75622
Reviewed-by: Paul Berry <paulberry@google.com>
In a named mixin application, the superclass doesn't include the last
type appearing in the "with" clause, so that class isn't considered a
superclass constraint.
Fixes some test cases broken by 46e5954b0a.
Change-Id: I2e824d38017fe2c7eaa23e8f185cea07fe2222b7
Reviewed-on: https://dart-review.googlesource.com/75940
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Now that we have an explicit syntax for mixins that is available all
the time, we have to do mixin inference error checking all the time,
not just when the "--supermixin" flag is supplied.
This required fixing several minor bugs:
- ErrorVerifier._checkForMixinSuperInvokedMembers did not properly
handle a mixinElement argument that was a ClassElementHandle.
- ErrorVerifier._checkMixinInference wasn't using the actual
substituted mixin types, causing errors to be wrongly reported when
a class declaration had multiple inferred mixins (this was the root
cause of #34404).
- Type names in "with" clauses in the resolved AST weren't properly
reflecting the mixin type arguments that had been inferred.
Fixes#34404.
Change-Id: Ia773233c66f8d9ab778f207689c73922e9e3a880
Reviewed-on: https://dart-review.googlesource.com/75792
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Dmitry Stefantsov