The existing specification was underspecifying potentially constant expressions,
effectively relying on evaluation to determine whether an expression was
potentially constant.
This change specifies potentially constant recursively using only the syntax
of the expressions.
Adds short-circuting to `?:`, `??`, `||` and `&&` expressions,
so for `String x`, the expression `x != null && x.length > 0`
is compile-time constant.
The original specification requred evaluation of the latter half
even when `x` is null. We can now avoid this because we can require that the
unused expression is a potentially constant expression without having to
check if it, or any part of it, is a compile-time constant expression.
Allows `x == null` and `x != null` as compile-time constant expression
independently of the type of `x`.
Allows `e as T` as a compile-time constant expression. Types are more
important in Dart 2, so you need a way to adjust typing in some cases,
even in compile-time constant expressions.
Change-Id: I02bf0b77013c3b3ced8cd46334db378787cc2d57
Reviewed-on: https://dart-review.googlesource.com/36220
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
We should avoid the situation where `class C extends A with M {}`
requires generation of noSuchMethod forwarders _in the superclass
`A with M`_ when neither `A` nor `M` has an implementation of
`foo`, but `A with M` has a non-trivial noSuchMethod.
If we _do_ generate those nSM forwarders, that will just obscure that
any attempt to invoke `super.foo()` in `C` should be an error.
Note that this is about generating forwarders _in the mixin application
which is the superclass_, it is not about copy-down of forwards from
the class `M` that was used to obtain the mixin in the first place.
Also note that it would be inconvenient to require all methods to be
implemented in `A with M` as used in `abstract C extends A with M {}`,
and it would also be rather funny if we were to say that `A with M` is
abstract when `C` is abstract, and concrete when `C` is concrete.
So I think the only reasonable choice is to make those superclasses
which are mixin applications abstract.
Note that dart:mirrors ought to reflect this, in a separate issue,
if it is not already the case.
Change-Id: If221b2c73b17bd55017d4d5ee4fdb8daf203e195
Reviewed-on: https://dart-review.googlesource.com/76640
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Also corrected some "includes" to "has" when talking about members of
an interface.
Change-Id: Ib8917c2a9f40fce82ab1e41e0e766c87065b168a
Reviewed-on: https://dart-review.googlesource.com/75880
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
---------------- 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>
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>
Lasse R.H. Nielsen