---------------- NEW description (old description shown at end):
This CL is now a reorganization, problem fixing, clarifying update
to dartLangSpec.tex which was created as part of the work on the
rules for call method extraction. That is, all the call method
extraction specific elements have been _deleted_ from this CL
(they will reappear as a separate CL later). This CL is now only
performing "general clean-up work" which is needed in order to
perform many kinds of updates (including call method extraction,
but also anything else where the dynamic semantics depends on the
static analysis & desugaring).
------------------------------------------------ OLD description
Introduced rules for call method extraction.
The previous update to dartLangSpec.tex dealt with invocations, but
omitted the transformation whereby `e` becomes `e.call` when `e` has
a type which is a class with a `call` method and the context expects
a value of type `Function` or of a function type. This CL adds some
rules dealing with that and introduces a concept for the transformation
itself.
One part is missing for the initial patch set: There are no rules
specifying that call method extraction should be applied to actual
arguments. The problem is that static checking of actual arguments
to various invocations (function expression invocation, ordinary
method invocation, super invocation, etc.etc.) seems to be "delegated"
partially to section `Binding Actuals to Formals`, but that section
never defines the syntax for the function which is being invoked and
it is in general rather dynamic in nature. So I'm not quite sure
that the references to static checking at the end of that section
are located optimally.
Some adjustments may therefor be needed before we can specify this
particular feature for actual arguments.
Change-Id: Ia2ab6f16cd50e10a3c467722035f0dc4adb50587
Reviewed-on: https://dart-review.googlesource.com/51323
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
The previous phrasing ("A constant expression is ... a literal string
where any interpolated expression is a compile-time constant ...") was
ambiguous: did it mean "... where at least one interpolated expression
is a compile-time constant ..." or did it mean "... where every
interpolated expression (if there are any) is a compile-time constant
..."?
Clearly the intended meaning is that all interpolated expressions are
required to be compile-time constants, otherwise we would allow
nonsense like this:
void f(int i) {
const x = 0;
const s = "$x $i"; // Ok because x is const (!)
}
Changing the word to "every" avoids the ambiguity.
Change-Id: I3a1dd38a8bc0dc9cddc7b504ea8e7de5afdf8990
Reviewed-on: https://dart-review.googlesource.com/74321
Reviewed-by: Leaf Petersen <leafp@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This updates the Dart language spec to allow
```
class C with M
```
where currently the above declaration would require `extends Object`.
Change-Id: Ibb5834b264be7b2c5adb79dfa9a24ad5e1fa539a
Reviewed-on: https://dart-review.googlesource.com/73684
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
Commit-Queue: Dan Rubel <danrubel@google.com>
The valid return tests were misnamed and hence not run. Also remove
duplicate tests from one file, and add status to the informal proposal.
Change-Id: I20179e81a0281302056f601ee3b7a51e2aec180e
Reviewed-on: https://dart-review.googlesource.com/73562
Commit-Queue: Leaf Petersen <leafp@google.com>
Reviewed-by: Kevin Millikin <kmillikin@google.com>
\; caused the following compilation error
! Missing $ inserted.
<inserted text>
$
l.7845 }
I have removed the backslash, and placed the semicolon between a pair
of $ to make it render like the one in the grammer-environment.
Change-Id: If57e61f61b460d159b6f14d70c9c9f343114cf70
Reviewed-on: https://dart-review.googlesource.com/71760
Commit-Queue: Daniel Hillerström <hillerstrom@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
The current specification only prohibits expressions statements where the
expression *is* a map, not those that *start with* a map.
Implementations have always rejected those starting with a map.
Bug: http://dartbug.com/725
Change-Id: I805a6f82d1afdcf335aff73e74dac1f14e5a6afe
Reviewed-on: https://dart-review.googlesource.com/71247
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
In changing the proposed spec to address comments in a way that was intended to be
non-breaking, I accidentally introduced some new (unintended) restrictions. This
fixes the spec, rolls back the change in analyzer, and adjusts the language tests
appropriately.
Change-Id: I487b0eaacbfa1447d4ee909c0a56e435c2088990
Reviewed-on: https://dart-review.googlesource.com/70462
Reviewed-by: Mike Fairhurst <mfairhurst@google.com>
Also remove 64-bit constraint on integer literals when compiling to JavaScript.
Effectively, all integer literals are treated the same way when compiling to JavaScript numbers.
Change-Id: Ib625457d65c40600291edbf391c82f37ad27701a
Reviewed-on: https://dart-review.googlesource.com/70144
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
We need to clarify the following case:
`dynamic foo() => print('');`,
`dynamic bar() { return print(''); }`
that is, using `return e` where `e` has type `void`, when the return
type of the enclosing function is `dynamic` (inferred or explicit).
We do not currently have any elements in the generalized-void.md
whitelist for that, so it's an error. However, invalid_returns.md
from https://dart-review.googlesource.com/c/sdk/+/60401 implies
(patchset 6: line 19-20 and 34-35) that it is allowed.
It is my impression that we agree on invalid_returns.md, and also
that it describes the current behavior (maybe not 100%?).
This indicates to me that we should, probably, add an element to
the above-mentioned whitelist to allow it.
This CL makes that change to generalized-void.md.
Change-Id: I0326081960deda907b3b4ff34bd2d60f7c9dc35b
Reviewed-on: https://dart-review.googlesource.com/64341
Reviewed-by: Erik Ernst <eernst@google.com>
The issue was raised recently that there must be generated forwarders
for some method signatures that we had not previously mentioned in
nosuchmethod-forwarders.md: Private methods with an inaccessible name,
that is, private methods declared in a different library than the
current target of nSM forwarder generation.
Given that such forwarders are semantically significant (a tear-off
performed in the library where the abstract private method declaration
is located would tear off a generated forwarder, rather than causing
an invocation of `noSuchMethod`), we need to specify this.
This CL adds such a specification to nosuchmethod-forwarders.md.
This CL addresses SDK issue #33725, and SDK issue #33727 is related
being concerned with the implementation in the common front
end.
Change-Id: Iedbcdd8b4c8df95c6038022f72b3211ec1b76649
Reviewed-on: https://dart-review.googlesource.com/64380
Reviewed-by: Erik Ernst <eernst@google.com>
This mostly documents and regularizes existing (post bug fix) semantics,
with a small additional restriction on returning `void` from an async
function.
Change-Id: Ic1a302aeb666fa73ca2b7e23072394490bb4fe76
Reviewed-on: https://dart-review.googlesource.com/60401
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
This CL adds a new feature specification for 'generic function
instantiation' (aka partial specialization, type-curried invocation,
etc.), which amounts to implicitly obtaining a non-generic function
from a denotation of a generic function when the typing requires the
latter.
This feature spec relies on type inference, but as a black box (so
it can hardly be incompatible with any current or future version of
type inference in Dart).
Note that it is a restricted version of generic function
instantiation which is specified here, it only supports global and
static functions and instance methods; function literals and first
class function values are not supported.
I just learned from Vijay (Mar 23, 3pm CET) that first class functions
_do_ support generic function instantiation in some existing
implementations. So maybe there is no problem supporting them, and
we should just eliminate that restriction?
Here is a rendered version of the document, refreshed to match patch
set 19: https://gist.github.com/eernstg/bf816d3495e9b87ab6eb958ba707d016
Change-Id: Ie1fd601d3e359bfb5f4616f8ec68a110f42e01b7
Reviewed-on: https://dart-review.googlesource.com/47043
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
The current specification seems to allow (or even mandate) that a
redirecting constructor (factory or generative) must be considered as a
syntactic shorthand for an invocation of the redirection target, with
no checks applied statically or dynamically according to the
declarations in the redirected constructor. So the following would be
OK:
class A {
A(num n) { print(n); }
A.foo(int i): this(i);
}
main() => new A.foo(3.0);
This CL changes dartLangSpec.tex to mandate all the checks (static
and dynamic) for the declaration of the redirecting constructor as
well as each one of the redirection targets.
Note that the analyzer already rejects the above program, which
lessens the disruption and the implementation burden, but compilers
would presumably need to have the dynamic checks implemented.
Underlying issues: https://github.com/dart-lang/sdk/issues/31590,
https://github.com/dart-lang/sdk/issues/32049,
https://github.com/dart-lang/sdk/issues/32511.
Change-Id: Icc15da6b817e4e678cdfc8829a1e06458756eb4b
Reviewed-on: https://dart-review.googlesource.com/28140
Reviewed-by: Leaf Petersen <leafp@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
We did not previously prevent `class C implements FutureOr<int> ..` and
similar declarations. However, it offers only very little value to
allow this, and possibly creates some complications. This CL makes all
these subtype relationships a compile-time error.
The wording of the constraint on `\WITH{} clause` was also adjusted to
remove some potential interpretations which are unintended (like
preventing `with List<dynamic>`, which should be OK).
Change-Id: I626c2767befa7a3cb3092b0ba5cb463e9456d431
Reviewed-on: https://dart-review.googlesource.com/63583
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
We noted in issue https://github.com/dart-lang/sdk/issues/33709 that
the language specification prevents usage of `Null` as the bound
of a type variable, because that makes the bound a subtype of
the type variable itself (which is otherwise a symptom of having
a cyclic declaration like `X extends X`).
This CL adjusts the wording such that it will be possible to use
`Null` (or whatever the denoteable bottom type is called) as a
bound.
Change-Id: I46a5ce6055f3af322a6b93ac38ca2829ce23a26c
Reviewed-on: https://dart-review.googlesource.com/63420
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Change-Id: I2760f333c96470dd3a58dc8d9c389a5c1242a83f
Reviewed-on: https://dart-review.googlesource.com/63384
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
Change-Id: I3c6fe9d27aad387a55f9a003d94faa6a9a72f227
Reviewed-on: https://dart-review.googlesource.com/44741
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
Don't use $e$ for two different things, and specify static type.
Fixes#19517.
Bug: http://dartbug.com/19517
Change-Id: Ieb30fc05dc305f25526b05b2005a1a81a88e2009
Reviewed-on: https://dart-review.googlesource.com/61881
Reviewed-by: Erik Ernst <eernst@google.com>
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
The text still uses "with the same URI" as a proxy for "being the
same library" (as it always did). We may wish to change that to
something which will catch the case where different URIs denote the
same library.
Note that this is concerned with the specification,
the feature has been implemented in
08de1b30aa.
Closes-bug: #33225
Change-Id: I678379e98a98c2a021ce2e02c8d942c074ff583c
Reviewed-on: https://dart-review.googlesource.com/60660
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Also update the `int` class documentation.
Change-Id: I2de6c62aa9642c18134effa8187a12902d5f2259
Reviewed-on: https://dart-review.googlesource.com/58204
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
Argh, the `git cl upload` was waiting for an `ENTER` press when I
landed CL 56487. This CL just deletes that TODO comment.
Change-Id: I58843d8ae984363ca1b8bacd2f735efa50c9b666
Reviewed-on: https://dart-review.googlesource.com/60249
Reviewed-by: Erik Ernst <eernst@google.com>
Change-Id: I4a8fc32071804c5edd0f7aab905ea4402df4414d
Reviewed-on: https://dart-review.googlesource.com/60102
Reviewed-by: Erik Ernst <eernst@google.com>
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
TBR: This CL only adds a missing changelog entry for the commit
08c893d55b.
Change-Id: I4963dbebc090e95b26ce043586cfa2db0df95f3c
Reviewed-on: https://dart-review.googlesource.com/57502
Reviewed-by: Erik Ernst <eernst@google.com>
As of patchset 5: The ruleset concerning class member conflicts
(apart from simple name clashes) has now been simplified
considerably, and it's expressed in one location, in a new section
(the locations where we previously had such rules are now
`\commentary{}` with a reference to the new section).
The old rules and the new simplified rules specify the same set
of conflicts (in that sense, patchset 4 == patchset 5).
The old description below gives details about what was changed
from the start of this CL until patchset 4.
------------------------------- OLD description:
Added conflict for constructor and setter with "the same name".
Discussed the inconsistent approach to conflicts between named
constructors and instance members with Lasse; we agreed that it
is confusing if we allow the constructor `C.n` to coexist with the
instance method/getter `n` and instance setter `n=`, except that
they must be inherited rather than declared in the enclosing class
`C`, so I adjusted the wording such that only _static_ members
conflict with named constructors.
One more reason why there is no conflict between `C.n` and an instance
member named `n` or `n=` is that the latter can _never_ be denoted
by `C.n` (but static members can be denoted by `C.n`, also in `C`).
Change-Id: I012e772ae6473fddd8f9944553d69e6a6ceeb2f9
Reviewed-on: https://dart-review.googlesource.com/56800
Reviewed-by: Leaf Petersen <leafp@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
This CL adds an example to super-bounded-types.md in order to motivate
the definition of what it means for a parameterized type based on a
type alias to be super-bounded. The definition says that we must check
the actual type arguments relative to the formal type parameter
list of the given `typedef` as well as the right hand side, replacing
the formals by the given actual type arguments. The example shows that
the right hand side can be ill-bounded even though the check that we
apply based on the formal type parameter bounds (that is, the check
that we apply to class types) succeeds.
A rendered version of super-bounded-types.md corresponding to patchset
6 is available here:
https://gist.github.com/eernstg/fc12eeb23064a2578a936b443461dde4.
Change-Id: I33dc6ced592f53160bc6f933558bfface46cd329
Reviewed-on: https://dart-review.googlesource.com/56668
Commit-Queue: Erik Ernst <eernst@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
This CL changes dartLangSpec.tex to say that 'closurization' takes
place (rather than just saying that it's a 'function') when a
global/local/static function is torn off, just like it always did
for instance methods. Also, it standardizes on using the phrase
'function object' to denote the run-time entity obtained from such
a closurization.
This addresses the non-generic parts of the request in #31665.
Change-Id: I6967a74df178fbb26af0f572b0471219d3169e4f
Reviewed-on: https://dart-review.googlesource.com/46860
Commit-Queue: Erik Ernst <eernst@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
Sergey pointed out a couple of name clashes, and I renamed some indices
in order to avoid them. At the same time, I fixed a couple of typos
and adjusted the whitespace to be more similar to other *.md files.
Finally, I adjusted the wording involving 'algorithmic' and 'syntax
directed' in order to make it explicit that they stand for the same
thing.
Change-Id: Ic03b907f4bdc722d9ba218d38077addf9cc4a777
Reviewed-on: https://dart-review.googlesource.com/50981
Reviewed-by: Leaf Petersen <leafp@google.com>
The "special case" text just says that the return type of `~/` on `int` is `int`, which is also its declared type, so the text isn't necessary.
Bug: http://dartbug/com/15650
Change-Id: Iba7fcc621e27dcba24dfdede2a0960f2f5ecd2f9
Reviewed-on: https://dart-review.googlesource.com/48144
Reviewed-by: Erik Ernst <eernst@google.com>
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
In response to the discussions in SDK issue 32414 about the typing of
members of `Object` when the receiver type is `dynamic`.
A rendered version of this document is available at
https://gist.github.com/eernstg/fc0094b0230ea18b9507092e50dab537
(uploaded as of patchset 6).
Change-Id: I3a74ecd5e7c9c9c05fadda5b1fa0d644561796e9
Reviewed-on: https://dart-review.googlesource.com/46247
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
Reviewed-by: Jenny Messerly <jmesserly@google.com>
As an example of a void-to-void data flow, consider `void x = foo();`,
where `foo` has return type `void`. In general, a void-to-void data
flow is a computation which is trivial (we may select one of two
branches in a conditional expression and otherwise only pass the value
on without any computation) where the expression being evaluated has
type void, and the target that receives the value is also of type
void.
This CL makes adjustments to generalized-void.md such that void-to-void
data flows are allowed.
Change-Id: Ia1722cd399c77c57cc5c61e9c10b7a84a18fe107
Reviewed-on: https://dart-review.googlesource.com/38060
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
It turns out that the special case for FutureOr<void> that I added in
https://dart-review.googlesource.com/c/sdk/+/35920 was misunderstood,
nobody really wanted it.
This CL removes all references to `FutureOr` in generalized-void.md,
which removes that special case and also the concept of types that are
"void equivalent" (because such types are not used any more).
The message here is that we are now more consistent in our protection
of developers against accidentally discarding a value which is
meaningful (just like `void foo() { return 42; }`), because they've
forgotten that the return type is `void`.
Change-Id: Ia4e6e00b2d33ff434923de7eb78d000cd7cc1c3e
Reviewed-on: https://dart-review.googlesource.com/41822
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
Change-Id: Ic6eeffd2e3d348f636af5ab4644cc60b87e85506
Reviewed-on: https://dart-review.googlesource.com/29060
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
A similar rule applies to asynchronous for-in loops.
Change-Id: I88ba234c27a38167eaac0350d269e88894a0fe9e
Reviewed-on: https://dart-review.googlesource.com/35920
Reviewed-by: Leaf Petersen <leafp@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
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>
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>
