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>
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 .
The informal spec of generalized void used to allow a `typeTest` on
an expression of type void. This CL removes that permission, thus
leaving only `as` as a narrow escape hatch from void, as decided at the
language team meeting on 2017-08-15.
R=lrn@google.com
Review-Url: https://codereview.chromium.org/3001063002 .
Currently you can write
assert(() { ... });
and the function will be called and the return value used as the assert test.
This feature isn't really worth its own complexity - if you want to get the same effect, you can just write all the function:
assert(() { ... }());
With asserts in const initializer lists, where the function call is not possible anyway, the feature went from being not very useful to being actual an complication and exception for users to remember.
R=eernst@google.com, rnystrom@google.com
Review-Url: https://codereview.chromium.org/2974763002 .
It turned out to be "instance variable" or "static or instance
variable" in all cases. I considered writing "member variable" for the
latter, but we would then need to introduce that phrase somewhere, and
maybe refer to it at each usage, which would be more verbose.
Fixes#24333.
BUG=
R=lrn@google.com
Review-Url: https://codereview.chromium.org/2613293002 .
Add `rethrow` as one of the statements that are allowed to end a switch case
without a warning.
Change wording to not claim that `throw` is a statement.
Also allow wrapping case statements in a block statement without causing
more warnings. Currently, a `case 4: { break; }` is required to warn because
the last statement is a block statement, not a break statement.
Fixes issue #27650
BUG= http://dartbug.com/27650R=eernst@google.com, floitsch@google.com, rnystrom@google.com
Review URL: https://codereview.chromium.org/2447613003 .
If the part declaration is non-empty, it will always cause a compile-time error anyway due to duplicate declarations in the library scope. This just makes it explicit that it's an error in all cases, and avoids the special case of the empty part file being silently accepted until you put something in it.
R=eernst@google.com
Review URL: https://codereview.chromium.org/2371743002 .
Now requires the type to be a supertype of `Iterable<T>`/`Future<T>`/`Stream<T>`
for some `T`. This allows, say, all `Future<T>` return types for `async` but
disallows using a different class implementing `Future`:
```
MyFuture foo() async {}
```
gives a static warning (error in Dart 2) because the return type is statically
known to be unsatisfied.
Fixes issue #27470
BUG= http://dartbugcom/27470R=eernst@google.com, floitsch@google.com
Review URL: https://codereview.chromium.org/2392513002 .
The current definition requires the expression to be valid and
compile-time constant if constructor parameters are considered
compile-time constants with types appropriate for their context.
This is necessary but not sufficient, so this CL adds the further
requirement that the expression must also be a valid (not necessarily
constant) expession if the parameters are considered non-constant
variables.
This rules out the case:
const C(x) : y = const [x];
where the current specification would, technically, allow it as a
potentially constant expression and therefore be a valid const
constructor. In practice it would never work if the constructor is
used with "new" instead of "const".
This is not really a specification *change* - existing implementations has this restriction anyway.
Addressed the concern of #24970.
BUG= http://dartbug.com/24970R=eernst@google.com, gbracha@google.com
Review URL: https://codereview.chromium.org/1465473002 .
Hash values are now computed for each "paragraph" starting with \LMHash
(which includes subsequent grammar, dartCode, itemize blocks, but stops
at \section-like commands). Now addlatexhash.dart expects three arguments
(first the source latex file, then the destination simplified and
hash-value-annotated latex source file, and finally a file name used to
create the list of hash values emitted). Adjusted testing accordingly.
Added a test for robustness of the hash value generation: It is checked
that lots of different "unimportant" changes make no difference for the
generated hash values (e.g., we can add/remove comments, change white
space, add \commentary{..} etc. without changing the hash values).
In order to ensure that all "structure" commands in the spec have a label,
I added an \LMLabel{..} a handful of places, following the style which is
used throughout the spec.
In dart.sty, the \renewcommand that made \LMHash{} produce a fixed
hash value has been removed such that the actual hash values are now
inserted into the generated spec PDF/DVI file. Tests have been adjusted
to handle this difference between the spec with and without hash values
when comparing the two.
R=gbracha@google.com, lrn@google.com, ricow@google.com
Committed: https://code.google.com/p/dart/source/detail?r=41658
Reverted: https://code.google.com/p/dart/source/detail?r=41662
Review URL: https://codereview.chromium.org//652993005
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@41687 260f80e4-7a28-3924-810f-c04153c831b5
Hash values are now computed for each "paragraph" starting with \LMHash
(which includes subsequent grammar, dartCode, itemize blocks, but stops
at \section-like commands). Now addlatexhash.dart expects three arguments
(first the source latex file, then the destination simplified and
hash-value-annotated latex source file, and finally a file name used to
create the list of hash values emitted). Adjusted testing accordingly.
Added a test for robustness of the hash value generation: It is checked
that lots of different "unimportant" changes make no difference for the
generated hash values (e.g., we can add/remove comments, change white
space, add \commentary{..} etc. without changing the hash values).
In order to ensure that all "structure" commands in the spec have a label,
I added an \LMLabel{..} a handful of places, following the style which is
used throughout the spec.
In dart.sty, the \renewcommand that made \LMHash{} produce a fixed
hash value has been removed such that the actual hash values are now
inserted into the generated spec PDF/DVI file. Tests have been adjusted
to handle this difference between the spec with and without hash values
when comparing the two.
R=gbracha@google.com, lrn@google.com, ricow@google.com
Review URL: https://codereview.chromium.org//652993005
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@41658 260f80e4-7a28-3924-810f-c04153c831b5
Introduced support for adding SHA1 hash valued location markers
at several levels in the language specification, added long explanatory
comment at the end, added a script 'addlatexhash.dart' to normalize
spacing, remove comments, etc., in the spec, such that the hash values
are more robust than they would be with a direct usage of the spec.
The script passes the "dvi2tty test", that is, when the location markers
are empty, the resulting *.dvi files created from dartLangSpec.tex and
from the version processed by the script give rise to the same text via
dvi2tty, i.e., the script does not destroy the spec.
R=gbracha@google.com, ricow@google.com
Review URL: https://codereview.chromium.org//646003002
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@41191 260f80e4-7a28-3924-810f-c04153c831b5