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>
Change-Id: I1feda4f3104ca100425233fb7f339a412a885f9f
Reviewed-on: https://dart-review.googlesource.com/34743
Reviewed-by: Erik Ernst <eernst@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Commit-Queue: Lasse R.H. Nielsen <lrn@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>
Change-Id: I6bbf51b7f3c5fd46d8ce59e860cf615e26308560
Reviewed-on: https://dart-review.googlesource.com/21346
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Commit-Queue: 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>
Change-Id: Ieb8e323a37f66713067f8a33a5d3a8596e840458
Reviewed-on: https://dart-review.googlesource.com/14401
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
Change-Id: Ie4b05f16006743207be76e26195ff345bf2efc6b
Reviewed-on: https://dart-review.googlesource.com/5765
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Commit-Queue: Erik Ernst <eernst@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>
Change-Id: I2c2857f5e32328bfe4693038e7ef376f8633758e
Reviewed-on: https://dart-review.googlesource.com/12296
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
