It is a compile-time error if an interface appears multiple times
across the extends and implements clauses.
This CL implements a check to detect the aforementioned case. A
previous commit implemented this by expanding and refactoring the
restricted super types check in source_loader.dart
(c.f. checkSemantics method). The restricted super types check decides
whether a type is allowed to appear in an 'extends', 'implements', or
'with' clause. However, it turned out it may have sat too early in the
compilation pipeline as it failed to detect the following case
class A implements Object {}
I decided that it was somewhat suboptimal to implement a special case
for "Object". Therefore I have moved the check to a later stage in the
pipeline, where classes without a super class have had the Object
class injected as their default super class. The check is now
implemented in kernel_class_builder.dart (c.f. checkSupertypes
method).
Closes https://github.com/dart-lang/sdk/issues/34193
Change-Id: Ie7153c896337b589118cac4b80e9df8ea5a09daa
Reviewed-on: https://dart-review.googlesource.com/70864
Commit-Queue: Daniel Hillerström <hillerstrom@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
This is a bunch of renames and cleanup in preparation for
my next CL with basic mixin declaration support.
Rename listener events:
* handleClassImplements to handleClassOrMixinImplements
* beginClassBody to beginClassOrMixinBody
* endClassBody to endClassOrMixinBody
Rename parser methods:
* parseClassMember to parseClassOrMixinMember
* parseClassBody to parseClassOrMixinBody
* skipClassBody to skipClassOrMixinBody
Also:
* Change test expect from "ClassBody" to "ClassOrMixinBody"
* Rename message ExpectedClassBody to ExpectedClassOrMixinBody
* Update text of MISSING_CLASS_BODY to include mixin
* Rename IdentifierContext.classOrNamedMixinDeclaration to classOrMixinDeclaration
Change-Id: Iaa554cc859e1e665475c0eb544895a311c06395a
Reviewed-on: https://dart-review.googlesource.com/70881
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Dan Rubel <danrubel@google.com>
Specification disallow name conflicts between
- type variables and class names
- type variables and getter names
- type variables and member names
Although not present in current specification, the language team confirms that
it is also supposed to be a compile-time error if there is conflict with a setter.
Closes https://github.com/dart-lang/sdk/issues/33827
Bug:
Change-Id: Ia25bc91c3287f93ae43faae121a1f9d81b179c6b
Reviewed-on: https://dart-review.googlesource.com/70500
Commit-Queue: Daniel Hillerström <hillerstrom@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
The rules for void are changed to allow uses of void where we
previously had a warning, such as the case of assignment to a
variable of type void or passing as a parameter of type void.
Change-Id: I1c1513b0000fa1c8eedbe2645fab503b28024fa3
Reviewed-on: https://dart-review.googlesource.com/70265
Reviewed-by: Daniel Hillerström <hillerstrom@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Commit-Queue: Kevin Millikin <kmillikin@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>
Extends the illegal return type check for async functions to cover
illegal return types for functions marked async* or sync* as well.
Adds new error messages for illegal return types of functions marked
async, async*, and sync*. These error messages conform with those
produced by the analyzer.
Closes https://github.com/dart-lang/sdk/issues/33068
Bug: www.dartbug.com/33068
Change-Id: I6d8690537139d3d094a4e295fcac9de4f4a7f0af
Reviewed-on: https://dart-review.googlesource.com/69581
Commit-Queue: Daniel Hillerström <hillerstrom@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
The scanner associates '<' with '>' and '>>',
but the parser cannot use '<'.endToken/endGroup reliably
and wastes time updating that token's endToken/endGroup field.
This CL updates type info parsing to ignore '<'.endGroup
and step through the token stream (which it has to do anyway),
for improved parsing.
This CL causes a handful of existing tests to fail (marked as @failingTest)
and test failures will be addressed in a subsequent CL.
Change-Id: I788e9a74cd2891f98f44bba15d5669febfec6c64
Reviewed-on: https://dart-review.googlesource.com/70001
Commit-Queue: Dan Rubel <danrubel@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
declared return type of an async function is a super type of Future<T>
for any T. In case the check is not successful an error message is
produced. The location of the name of the offending function
declaration is used as location information for message. Ideally we
would use the location of the type, so until types get annotated with
location information the error message remains suboptimal.
This closes#33425 and closes#34057.
Thanks to dmitryas and jensj for their helpful guidance.
Bug: dartbug.com/33425 dartbug.com/34057
Change-Id: I3b3dadc25b574422ea1f38671fe8cba3ffdd494c
Reviewed-on: https://dart-review.googlesource.com/69307
Commit-Queue: Daniel Hillerström <hillerstrom@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
This is the first CL of several needed to fix typedef parsing
when there is no space between the type parameters and the `=`.
typedef F<T>= T Function(T);
* Fix some typedef parsing failures
* Add new consts for simple type var ending with ">>" and ">="
* Update computeType and computeTypeParamOrArg to return new consts
* Extract splitGtEq/GtGt/GtGtEq from splitEndGroup
* Hide internal TypeInfo and TypeParamOrArgInfo consts
Change-Id: Ice550f5b15df1f3cad616a2a342644974f14d8ee
Reviewed-on: https://dart-review.googlesource.com/69261
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Dan Rubel <danrubel@google.com>
This extracts and refactors a sizable chunk of dartdoc parsing out of AstBuilder
and into the fasta parser. Parsing dartdoc does not happen unless the listener
calls the new fasta parser parseCommentReferences method.
The new parseCommentReferences method generates a handleCommentReferenceText
event for each comment reference encountered. The listener calls the scanner
to tokenize the comment reference and forwards the result to a new
fasta parser parseOneCommentReference method. This method generates either
a handleCommentReference or a handleNoCommentReference depending upon
whether or not a reference is parsed.
parser.parseCommentReferences
* generates handleCommentReferenceText events
* returns # of events generated
listener.handleCommentReferenceText
* calls parser.parseOneCommentReference
parser.parseOneCommentReference
* generates either handleCommentReference or handleNoCommentReference
There are further improvements to be made, but I believe this chunk
will allow progress to be made on the kernel side.
Change-Id: I393dc4d1d4791b3d7a529f6cb3c16db3a5befddf
Reviewed-on: https://dart-review.googlesource.com/68461
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Dan Rubel