External fields whose type is non-nullable don't need to be
initialized (in fact they can't be initialized), so we shouldn't
report "uninitialized field" errors for them.
This CL also adds some basic tests of the functionality of external
fields, making sure that the getters and setters they introduce are
properly resolved and that their types are properly respected by
inheritance checks.
Change-Id: I9b08727ab0d45d24801af3721e332c7ec21d08bc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/157840
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
I would have prefered to have renamed them all to undefined_super_member,
but that would have broken existing links. Some day we should add the
support necessary to allow for forwarding so that we can rename codes.
Change-Id: I81e416407e3464b5b60a4dbbfe60a375eb47bb84
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/157921
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Although these error conditions are not reported by the parser, the
language grammar does not permit them, so from a customer perspective
they are parser errors. Accordingly, they have been assigned
ParserErrorCodes and reported by the AstBuilder, as we do for other
similar errors.
Change-Id: I79d0ad1dcad518981b8b649c117df326279008f7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/157800
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
There are three ways to initialize a field, so we have to check for
three error conditions:
- At the declaration site
- Via a field formal parameter
- Via a constructor initializer
Fixes#42981
Change-Id: Ifc32a28ffb62d60fd2171d4980e88da9eebcb481
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/157664
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This CL covers two cases: when an abstract field appears in a concrete
class (which we report as CONCRETE_CLASS_WITH_ABSTRACT_MEMBER, just as
we do for abstract methods), and when a concrete class implements a
class with an abstract field, but fails to supply the necessary
concrete implementation(s) (which we report as
NON_ABSTRACT_CLASS_INHERITS_ABSTRACT_MEMBER_*, just as we do for
abstract methods).
Change-Id: I94bdbafc4ed7b058d9b33b3774e79cb55393380b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/157600
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Abstract final fields don't need to be initialized (in fact they can't
be initialized), so we shouldn't report "uninitialized field" errors
for them.
This CL also adds some basic tests of the functionality of abstract
final fields, making sure they don't introduce setters, and that the
getters they introduce are properly resolved and that their types are
properly respected by inheritance checks.
Change-Id: I885f23ce7ca554ba8f48e932ba9d76e128ac0bbd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/157520
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Abstract fields whose type is non-nullable don't need to be
initialized (in fact they can't be initialized), so we shouldn't
report "uninitialized field" errors for them.
This CL also adds some basic tests of the functionality of abstract
fields, making sure that the getters and setters they introduce are
properly resolved and that their types are properly respected by
inheritance checks.
Change-Id: I1fe7b6f40456d03533b85403ec6f428656820706
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/157466
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
`DartType.replaceTopAndBottom` needs to do different things for
NNBD/legacy code. Move this behavior into TypeSystemImpl with its own
responsible visitor.
Fixed: 41926
Change-Id: Ib0eca2384276998d5fdf99f2d9a210d86c999afa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/156443
Auto-Submit: Mike Fairhurst <mfairhurst@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
As opposed to the parent CL which creates a new error for cases where no
non-generative constructor is available at all, these improvements
include a bugfix to the previous error message.
The previous message was incorrect in saying 'expected {0} but factory found',
because the argument passed to '{0}' was the factory constructor that
was found, rather than any kind of expected constructor signature.
Fixed.
Also, for implicit constructors, break out the error message to
deliberately explicitly describe that this affects the implicit
constructor.
I considered making an error code for implicit super initializers as
well, (ie `class Foo extends Bar { Foo(); }`), but don't think it is
necessary/common/etc.
Change-Id: I0643ad00abbfb2848cbd2f8f1f83e7c33d4fb846
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/155831
Commit-Queue: Mike Fairhurst <mfairhurst@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
In the case of extending Exception, the raised error is around the
configuration of the constructors. However, there is no valid
configuration of constructors to be found, and therefore, the better
user facing message is to say that the class cannot be extended as
written.
Change-Id: I5950d438877c450c44cdc914f9f20d7779a64768
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/154126
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Konstantin Shcheglov