-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[analyzer] No error produced for not-implementing-final-classes through legacy libraries. #52078
Comments
It's not shared code so I'm gonna split this bug. And this is in the same area as the base implements bug, will look into it |
I think we're probably just going to accept this behavior here. It would be breaking to change this post release, and I don't see it rising to cherry pick level at this point. I'm also not 100% convinced that it's what we want. The problem here is in the legacy library. The Dart 3 code has no ability to control or fix the problem. Eventually, the legacy library will have to do something other than implement MapEntry, and at that point, the Dart 3 code will be correct. Until then, it seems better to just let the code work. |
@leafpetersen, if I'm reading the timezone info correct then your comment here was written before the language team meeting yesterday, and I believe the decision at that meeting was to adjust the tool behavior to fit the current specification (so class We do have co19 tests covering this case, but they are only being rolled in right now. For example, https://github.com/dart-lang/co19/blob/master/LanguageFeatures/Class-modifiers/versioning_A03_t02.dart has a few dozen post-feature classes that implement a pre-feature class that implements or extends or mixes in a final platform class. |
… implements a core library base or final class. Bug: #52078 Change-Id: If97895b9560475f11e8236de87ad5880bdee97c3 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/300880 Reviewed-by: Lasse Nielsen <[email protected]> Commit-Queue: Kallen Tu <[email protected]>
… class. Checks an interface's supertypes for final classes and produces an error if the implementing bypasses a legacy library. This behaviour should only happen when a post-feature library implements a pre-feature library declaration that has a final class as a super declaration. Similar error to https://dart-review.googlesource.com/c/sdk/+/298320 Bug: #52078 Change-Id: Ie16edb2b231957dad7502fdab3d5faba93bc6773 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/300861 Commit-Queue: Kallen Tu <[email protected]> Reviewed-by: Konstantin Shcheglov <[email protected]>
@sgrekhov Just to let you know, the analyzer errors in https://github.com/dart-lang/co19/blob/master/LanguageFeatures/Class-modifiers/versioning_A03_t01.dart should now be added. Analyzer (not CFE yet) work for this bug is complete. |
@kallentu thank you! I checked the tests on the just built SDK on Linux x64. We had 3 failing tests for the case when superinterface chain goes through a pre-feature library versioning_A03_t01.dart - checks that Testing shows me that versioning_A03_t02.dart is fixed and passes now. But other two tests are still failing. I think they should be fixed as well
|
Sounds like we would need to reopen this issue, but I suspect there may be an issue which is a better fit (or a new one should be created, rather than reopening this one): This issue is about having an The failures in LanguageFeatures/Class-modifiers/versioning_A03_t01.dart and ..._t04.dart are caused by the fact that the CFE and the analyzer do not report a compile-time error based on the missing Is there an open issue about this situation? Otherwise we should probably handle it in a new issue. Edit: We now have #52321, covering the cases mentioned here. |
…f a core lib declaration through a 2.19 library and a 3.0 library. Cherry pick for the following behaviour from 3 different CLs. Error produced when a post-feature library implements a pre-feature library declaration that has a final/base core library class as a super declaration. Error produced when a post-feature library subtypes (but not implements) a pre-feature library declaration that has a final/base core library class as a super declaration. Fixes: #52406 Bug: #52315, #52115, #52078 Cherry-pick: https://dart-review.googlesource.com/c/sdk/+/302365 Cherry-pick: https://dart-review.googlesource.com/c/sdk/+/301503 Cherry-pick: https://dart-review.googlesource.com/c/sdk/+/300861 Cherry-pick: https://dart-review.googlesource.com/c/sdk/+/301442 Cherry-pick: https://dart-review.googlesource.com/c/sdk/+/300880 Change-Id: I2a192a157d417c1de7656aa624d3b10d9e67626e Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/302851 Commit-Queue: Kallen Tu <[email protected]> Reviewed-by: Konstantin Shcheglov <[email protected]> Reviewed-by: Johnni Winther <[email protected]>
Example:
and
This gives no errors, or warnings, in the front end or analyzer.
According to specification, you are not allowed to implement any interface which has any superinterface whose declaration is marked
base
orfinal
. (Unless you are, yourself, a pre-feature library and all such superinterfaces are in platform libraries.)Here
N
is not in a pre-feature library, so it gets no exemptions.M
has a superinterface markedfinal
, so it must not be implemented byN
.(We don't have a rule against
N
extendingM
, so its not like we can prevent everything, but we can prevent newimplements
of afinal
platform type in 3.0-libraries.)Filing as area-fe-analyzer-shared. Split this into two issues if it's two different bugs.
The text was updated successfully, but these errors were encountered: