The language team several times agreed to make it an error when a
non-void expression `e` is used in `return e;` in the body of a
function whose return type is `void`.
When `void` is changed from a near-bottom type to a top type, the
wording in the language specification (dartLangSpec.tex) does _not_
ensure that this is an error, because all types are assignable to
`void`, so we need a specific rule saying that it is an error.
This CL adds such a rule to the feature spec for generalized void.
It also adds a rule that makes it an error to have return type `void`
in a function marked `async*` or `sync*`, based on the reasoning
that they "are returning a Future/Stream/Iterable semantically",
and it would now be an error if they did that explicitly.
Change-Id: I22fed9e9fc6097bb50100a151b964045e41ef173
Reviewed-on: https://dart-review.googlesource.com/35680
Reviewed-by: Leaf Petersen <leafp@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
Description which is relevant as of January 2018:
The more aggressive approach where `const` is inserted whenever
possible (for instance creation expressions) and whenever required
(for composite literals), and `new` is inserted otherwise, is now
the agreed policy. This means that the remaining discussion is on
the specification of this policy, not the policy itself. This has
been true approximately since Dec 1st, 2017.
Here is a brief overview of the feature which is specified in the
document added by this CL:
The introduction of 'implicit creation' adjusts the grammar such
that instance creation expressions (such as `new C()`) can always
omit the keyword (`new` or `const`). The semantics is that these
expressions will still invoke the same constructor (which may
produce a fresh instance in case of a generative constructor, and
some object that may or may not be new in case of a factory),
as if `new` or `const` had been added implicitly. The choice of
whether to add `new` or `const` is made according to the policy
described above.
----------------------------------------------------------------------
Original description, FYI:
Copy of Rietveld 3012703002: magic optional const
Adjusted informal spec optional-new to insert `const` whenever possible
The current version of optional-new.md specifies that `const` should be
inserted into certain syntactic phrases (when specific identifiers
satisfy some constraints), but only when these phrases occur in a const
context.
This CL changes that approach and specifies that `const` should also be
inserted outside const contexts, if the resulting expression is a
correct constant expression.
We haven't yet decided on whether we want the current (predictable)
model or we want the more "magic" one specified in this CL; this CL
is intended to be landed if we choose the latter, and discarded if we
choose the former.
Change-Id: I602e7eaf3d4c7904277af45c6f62089c77bd5117
Reviewed-on: https://dart-review.googlesource.com/3160
Reviewed-by: Leaf Petersen <leafp@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
The covariant parameter related feature specs were written to specify
that overriding admits a type annotation `T` on a formal parameter as
long as `T <: S` or `S <: T` for every type annotation `S` on a
corresponding formal parameter in an overridden declaration (directly
or indirectly).
This CL changes the rules such that a covariant-from-class parameter
must satisfy the standard constraints (contravariance) instead, which
is needed in order to ensure that an important optimization (on self-
sends) is valid.
This makes the spec follow the actual implementation, i.e., the change
will not break any existing software.
Change-Id: Ic871cc16c09220a385d68d9ec32c7a06683db87b
Reviewed-on: https://dart-review.googlesource.com/37664
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
The Dart 1 specification of 'generic method syntax' had no status
indicator, it is now marked as 'background material' because generic
methods (in full) have been integrated into the language specification.
Several other changes of a similar nature.
Implication: It should now be possible for readers of these documents
to trust their status indication. As we go, we will need to update them
again, especially when something is integrated into the language
specification.
Do we want to migrate background material to another directory? Do we
want to rename the directory `informal` to `feature` or somesuch?
Change-Id: Ia3851bdbe7b5a46d71848c376906f95feb4db349
Reviewed-on: https://dart-review.googlesource.com/34663
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Remove places where you were technically allowed to add spaces between
individual characters, but no implementation actually allowed it.
Change-Id: I0a13c9e3995b897135cd578a7d8c114f7746f991
Reviewed-on: https://dart-review.googlesource.com/34640
Commit-Queue: Erik Ernst <eernst@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
This CL changes said document to drop support for requested generation
of forwarder in case of a conflict. Developers must then write a
disambiguating method implementation themselves.
Note that this is what we already agreed during discussions about
this feature, but I noted that it hadn't yet been written into the
document.
Also changes the status to 'under implementation'.
Change-Id: I31b3dd8d65438484824225ad7067d36462d26aa7
Reviewed-on: https://dart-review.googlesource.com/22421
Commit-Queue: Erik Ernst <eernst@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
In dartLangSpec.tex there used to be many white space anomalies, e.g.,
double spaces between words with no apparent justification
or multiple empty lines
or lines starting with indentation that wasn't justified by any
consistent rule that I could spot.
This CL fixes that.
It also adjusts the grammar rules to be formatted in a systematic way
which will be helpful for an update to use something else than
bnf.sty (that we can't distribute due to license problems).
In particular, when a right hand side is too long for one line it used
to flow into the next line just like text (so non-terminals would have
`-` inserted at locations where a natural language algorithm thought
the "word" could be split in two, and the indentation on the next line
was nonsensical). So now it uses `\gnewline{}` ("grammar newline") to
switch to a new line and indent somewhat. It also uses `\gcomma{}` to
produce a quoted comma (which otherwise looks funny, because the `,'
becomes more like `, ' because the comma has a sort of built-in space
after it).
The command `\cd{...}` is gone and `\code{...}` is used everywhere.
Every sentence is now terminated by a newline. This doesn't mean that
every line is <80 chars, but it is at least much more readable (in
an editor whose window is really big), and it's consistent with the
more radical changes that we have made whenever we have made bigger
changes to a paragraph.
Finally, all comments on interface injection and all comments on
spread and rest arguments have been deleted. These comments contained
considerations about said features, but they did not contribute to
the discussions that we have had about the same or similar topics
(in particular because the comments relied on assumptions that do
not hold any more).
So it's a big diff, but a huge portion of it is white space fixes,
and the rest is very systematic. So it should be bearable, and we
would surely need to do the same things over time, otherwise.
Change-Id: Ia5922c22cb496792d394e76ce8c7bca7df1b4cc8
Reviewed-on: https://dart-review.googlesource.com/25000
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Update `return e;` in `async` function to do an implicit await if the value is async.
(We can make it an explicit await that also waits if it's not a future).
Make it explicit that we don't allow two different instantiations of the same interfaces.
Change-Id: I66de9ec55c1d55523d91e6d2bbebcb7d02ef301f
Reviewed-on: https://dart-review.googlesource.com/23663
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
The discussion about SDK issue 31305 showed that the definition of
covariant/contravariant/invariant occurrences need to be given
somewhere, and also that covariant-from-class.md is a reasonable place
to put it.
This CL adds those definitions there, based on Leaf's proposal in the
above-mentioned issue, and adjusts the definition of what it means to
be a covariant parameter such that the case where the relevant type
parameter occurs in the bound of a formal type parameter in a function
type is taken into account.
(It also reformats the document to stay within 80 columns and follow
the style of newer informal specs more closely, but that should be
easy to skip over because Gerrit colors white space changes
differently from "real" changes).
Change-Id: I0b0a688c616d0bb56755ceea08e1792abfa7936d
Reviewed-on: https://dart-review.googlesource.com/23422
Commit-Queue: Erik Ernst <eernst@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
The spec would sometimes use the reserved word (boldface) null, which
is an expression, when it really meant the value of that expression.
Since that value has a defined name, "the null object", use it
correctly and consistently.
The spec would also use the phrase "the null value", which presumably
just meant the null object. Replace occurrences of this phrase with
"the null object".
Bug:
Change-Id: Ibadeb97fe3bec67cd77d6a8d6c57e922cea265d3
Reviewed-on: https://dart-review.googlesource.com/22461
Commit-Queue: Kevin Millikin <kmillikin@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
The test language_2/built_in_identifier_prefix_test stated 'it is not
illegal to use a built-in identifier as a library prefix', which has
been untrue for quite a while, and then proceeded to check a number of
cases where said situation was used in practice. All of that is now
obsolete, so that test was split into several tests, each of which was
adjusted to test something which is relevant today.
The new tests include checks for the use of "known" identifiers (such
as `of`, `show`, `on` and a few more) which are mentioned explicitly
in the grammar, but which are neither built-in identifiers nor
reserved words.
The new tests gave rise to a number of status entries, including 25
crashes (so it is not just "expect `MissingCompileTimeError` here
because it's not strong mode").
Note that `Function` is considered to be a built-in identifier.
This makes no difference for the grammar, but it means that there
are no cases where `Function` is used as a library prefix.
If we insist that `Function` cannot be a built-in identifier then
we just need to add a few more grammar rules to all such things as
`import .. as Function;`, but I considered it less confusing to
include `Function` among the built-in identifiers and avoid adding
support for this.
Note that we haven't said anywhere that `Function` is a built-in
identifier, so we would need to adjust an informal/*.md file to say
that, to finish this off.
Change-Id: Ifa5bbd95022498480b7ee2e94605f81cd11d9696
Reviewed-on: https://dart-review.googlesource.com/21080
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
The spec was not self-consistent with respect to the usage of various forms
of 'run time' and 'compile time', even when using them as formally defined
terms (e.g., compile-time error).
Consistently follow the conventions: that 'run-time' and 'compile-time' are
adjectives and not nouns; that 'run time' and 'compile time' are noun
phrases containing an adjective and not adjectives themselves; and that
'runtime' and 'compiletime' are nonsense or at least jargon and are avoided.
Fixes https://github.com/dart-lang/sdk/issues/25883
Bug:
Change-Id: I0a9eb524bb43ed6c3a74e6ef038184bcbe979966
Reviewed-on: https://dart-review.googlesource.com/21345
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Commit-Queue: Kevin Millikin <kmillikin@google.com>
In the specification grammar docs/language/Dart.g, named parameters in
a new style `Function` type must now have a type. They used to support
a plain `identifier` form, which means that the type was omitted and
only the name given, but the informal spec did not allow this (and this
was a decision taken because we wanted to take a step towards the kind
of function types where it is always the name which is omitted if
anything is omitted, and this means that nothing can be omitted for a
named parameter).
Change-Id: Ib2538f5bafd1e044f0b4f22ea0a6b9a339f81501
Reviewed-on: https://dart-review.googlesource.com/19567
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
This CL modifies the Dart source used from test.py such that it takes
`syntax error` into account as an expected outcome in test files (so
that we can have `//# 01: syntax error` with a similar meaning as
`//# 01: compile-time error`).
For all tools except the spec_parser, `syntax error` is the same
outcome as `compile-time error`; that is, nobody else will see the
difference.
For the spec_parser, `syntax error` is the outcome where parsing has
failed; `compile-time error` is taken to mean some other compile-time
error, i.e., the spec_parser is expected to _succeed_ when the
expected outcome is `compile-time error`.
Test files in language and language_2 have been adjusted to use the
outcome `syntax error` where appropriate.
The status files in language and language_2 for the spec_parser have
been adjusted such that they fit all the new `syntax error` outcomes
in test files.
Other status files have been adjusted in a few cases where tests were
corrected (because a compile-time error which was clearly not intended
to be a syntax error turned out to be caused by a typo, which means
that the actual compile-time error has never been tested).
The spec grammar Dart.g was adjusted in a few cases, when some bugs
were discovered. In particular, the treatment of Function has been
changed: It is now known by the parser that Function does not take
any type arguments. This makes no difference for developers, because
they cannot declare a type named Function anyway, but it means that
a number of tricky parsing issues were resolved.
Dart.g was also adjusted to allow `qualified` to contain three
identifiers, which is an old bug (preventing things like metadata on
the form `@p.C.myConst`).
Change-Id: Ie420887d45c882ef97c84143365219f8aa0d2933
Reviewed-on: https://dart-review.googlesource.com/18262
Commit-Queue: Erik Ernst <eernst@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
This CL modifies tools/test.py such that it can run the spec parser
(after doing `make parser` in tools/spec_parser, and assuming that the
ANTLR 3 library is available at /usr/share/java/antlr3-runtime.jar)
with a command line like
`tools/test.py -c spec_parser -r none language/callable_test`
It also changes status files to have a name which follows the expected
patterns (e.g., `language/language_spec_parser.status`). Finally, it
adds/changes many entries in status files, such that parsing of the
directories `language` and `language_2` run successfully.
Change-Id: I82a22e32ac4fecd23ac0d4434bcac08f75dd8ffe
Reviewed-on: https://dart-review.googlesource.com/12680
Commit-Queue: Erik Ernst <eernst@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Eliminated the imprecise notion of an immediate subexpression.
Included missing rule for transformation of composite literals
(lists and maps). Some smaller fixes according to feedback by
mail.
Change-Id: I03e58dd24b370b797cda084bd064c6f0db22f8fb
Reviewed-on: https://dart-review.googlesource.com/4383
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
This CL updates section 'Function Expression Invocation' in
dartLangSpec.tex to specify that it is a static warning to use the
value of an expression of type `Object` as a function.
We still _allow_ using a `Function` and a `dynamic` value as a function
by means of `assignable`, because these two things together are rather
concise, and they say the right thing.
It is a bit convoluted, though, because `Object` seems to be OK
according to the first sentence, and then it's ambushed by the second
sentence. Proposals for a more elegant wording welcome! ;-)
Change-Id: I997399b9e10da339df359e9c6a339249ab97acf9
Reviewed-on: https://dart-review.googlesource.com/11480
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
This makes it possible to run the spec parser in a way which is a bit
more like the other tools that we have (e.g., tools/test.py):
> tools/spec_parse.py tests/language/callable_test.dart
It still requires the developer to run `make parser` in
tools/spec_parser and hence does not run on a buildbot, but it's one
step forward.
Change-Id: I68ad6cea55bc02dddac21558acec33fc4bfc1981
Reviewed-on: https://dart-review.googlesource.com/9620
Commit-Queue: Erik Ernst <eernst@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
The spec parser now parses all of language_2; many files are skipped,
but that is because they are multi-tests or because they contain
intentional syntax errors (negative tests).
Change-Id: I7061f0512702f3cb9631b32c79c3c1c1e2b7b0a6
Reviewed-on: https://dart-review.googlesource.com/8641
Commit-Queue: Erik Ernst <eernst@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
During migration of lib/mirrors/initializing_formals_test.dart to lib_2
it became apparent that strong mode makes it an error to have different
type annotations on an initializing formal and the corresponding field.
The language team discussed this and decided that we will take a middle
way: These type annotations can differ, but the initializing formal
must have a subtype.
This CL adjusts the spec to say that. In line with the rest of the
spec it is still a static warning (we will migrate all the static
warnings to errors as a separate step).
Change-Id: I66656c2933b7f86b78f0b06eadbf5edc0f58a3c6
Reviewed-on: https://dart-review.googlesource.com/7264
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
In https://github.com/dart-lang/sdk/issues/30732 the concern was raised
that the new Function type syntax does not support metadata on
parameter specifications (i.e., on normalParameterTypes and on
namedParameterTypes).
The implication of adding support for metadata in these locations is
that `@required` can be used on function types, which is the motivation
for submitting 30732.
We have always had support on parameter declarations in function typed
parameter declarations (`void foo(@A() int f(@A() String s))`), so in
this sense there is no new semantics to worry about (Lasse: "it doesn't
mean anything anyway!").
This CL modifies the generic-function-type-alias.md informal spec to
include this kind of metadata support.
Change-Id: I4520d330458242b31c991f62c03ca2f34f9c5e54
Reviewed-on: https://dart-review.googlesource.com/5762
Commit-Queue: Erik Ernst <eernst@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Currently the spec says that namedArguments of, say, a setter Invocation must
return the `const{}` map. That's badly typed for Dart 2(it should at least
be `const <Symbol,Object>{}`) and unnecessarily specific.
This change just requires the object to be empty and unmodifiable.
Also remove the spec handling invalidly overridden noSuchMethod.
That's not longer possible in Dart 2.
Change-Id: I3a983a44dd5939e42c85a53e9769f5961e03b986
Reviewed-on: https://dart-review.googlesource.com/6462
Reviewed-by: Erik Ernst <eernst@google.com>
The informal specifications of optional-const and optional-new used to
be incomplete, and this CL adds missing parts (transformation rules for
lists and maps, and for `assignableExpression`).
This version of the documents preserves the property that no `const` is
added without immediate syntactic justification.
The alternative (where `const` is used also in other contexts where
either `const` or `new` must be added, just because we can do that)
is not specified here, that'll be another CL. The corrections done in
this CL will be needed, anyway, so I separated the two.
R=lrn@google.com
Review-Url: https://codereview.chromium.org/3005833002 .
Erik Ernst