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 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>
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>
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>
Erik Ernst