mirror of
https://github.com/dart-lang/sdk
synced 2024-10-14 09:12:08 +00:00
004f564f40
A quirk of analyzer and CFE implementations is that they resolve property gets such as `foo.bar` to specific field or getter declarations that may be not be directly defined on the target type; for example if `foo` has type `B`, and `B` extends `A`, and `A` contains a field called `bar`, then `foo.bar` is considered to refer to `A.bar`, for example: class A { int? bar; } class B extends A {} f(B foo) { print(foo.bar); // Resolved to `A.bar`. } This is in contrast with the language specification, which makes a clean distinction between class _declarations_ and the _interfaces_ implied by those declarations. While a class declaration can contain (among other things) both getters and fields, which might be concrete or abstract, an interface doesn't distinguish between getters and fields, and is inherently abstract. The advantage of the analyzer/CFE approach is that it allows more intuitive error messages and "go to definition" behavior, which benefits users. But it has some ill-defined corner cases involving complex class hierarchies, because not every property access can be resolved to a unique declaration (sometimes a getter is multiply inherited from multiple interfaces, for example). The language spec approach has the advantage of being well-defined and consistent even in situations involving complex class hierarchies. When I initially implemented field promotion, I took advantage of this quirk of the analyzer and CFE implementations, so that I could make property gets that refer to field declarations promotable, while keeping property gets that refer to abstract getter declarations non-promotable. This caused unpredictable behaviors in the ill-defined corner cases. It also meant that in certain rare cases, a property access might not be promoted even when it would be sound to do so (e.g. a property access might refer to a private abstract getter declaration, but the only concrete _implementation_ of that abstract getter was a final field). This CL changes the rule for promotability so that any get of a private property is considered promotable, provided that the containing library doesn't contain any concrete getters, non-final fields, or external fields with the same name. It no longer matters whether the private property refers to a field or a getter. This rule is simpler than the old rule, restores the spec's clean distinction between class declarations and interfaces, and allows more promotions without sacrificing soundness. For additional details please see the breaking change announcement at https://github.com/dart-lang/sdk/issues/54056, as well as the original change proposal at https://github.com/dart-lang/language/issues/3328. Fixes https://github.com/dart-lang/sdk/issues/54056. Fixes https://github.com/dart-lang/language/issues/3328. Change-Id: I38ffcb9ecce8bccb93b1b2586a1222a0fb1005a7 Bug: https://github.com/dart-lang/sdk/issues/54056 Bug: https://github.com/dart-lang/language/issues/3328 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/337609 Reviewed-by: Konstantin Shcheglov <scheglov@google.com> Reviewed-by: Lasse Nielsen <lrn@google.com> Commit-Queue: Paul Berry <paulberry@google.com> Reviewed-by: Johnni Winther <johnniwinther@google.com> |
||
---|---|---|
.. | ||
argument_type_not_assignable_nullability_error_test.dart | ||
assignment_error_test.dart | ||
extension_property_error_test.dart | ||
field_error_test.dart | ||
for_in_loop_type_not_iterable_nullability_error_test.dart | ||
invalid_assignment_error_nullability_error_test.dart | ||
nullable_expression_call_error_test.dart | ||
nullable_method_call_error_test.dart | ||
nullable_operator_call_error_test.dart | ||
nullable_spread_error_test.dart | ||
property_error_test.dart | ||
this_error_test.dart |