This adds formatting support for upcoming language features:
- Named arguments anywhere
- Enhanced enums
- "super." parameters
It doesn't change the formatting of any existing code, so it should be
safe to roll this in without coordinating a pre-built SDK roll.
I also went ahead and ran the formatter on the related language tests
since before now they couldn't be formatted. (And I incidentally ran
the formatter on the other enum tests sitting in the same directory.)
Edit: Actually there is one small change to existing formatting: enum
declarations will now get a blank line inserted before them. Most hand
authored enums already have this so will be unchanged but I see a few
diffs when formatting generated code.
Change-Id: Icefd9f10bedc589312396cf0ddb8eafc418f8dbf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/235284
Auto-Submit: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
Reviewed-by: William Hesse <whesse@google.com>
Commit-Queue: William Hesse <whesse@google.com>
This CL makes a lot of small corrections in enhanced_enums_basic_test,
e.g., references to variables whose name is slightly different in the
declaration and at the use site.
[Edit: This CL no longer adds a new test, `enhanced_enums_error_test`
already covers all the situations tested by that new test.]
Change-Id: I9d2aabd5ab740b91463eff12a5c676136bf4ec04
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/233384
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
The tests check that expected errors actually happen.
There might be *too many* error markers in the tests,
since it's not clear *where* an error is reported.
Is a naming conflict reported for one or both conflicting declarations?
Is a conflict reported on the class declaration or on a conflicting
declaration?
The front-ends might need to remove themselves from some of the errors,
when the error reporting strategy is decided, but they should report
at least *one* error for each problem.
Also fixed bugs in the non-error `enhanced_enum_basic_test.dart` file.
Change-Id: I673244d1d5a8803e5b49d53150a2b3ab47522c89
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/231950
Reviewed-by: Erik Ernst <eernst@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
We use an extension getter instead of an instance getter because
it doesn't conflict with any potential existing or future enums
which want an element named `name`.
Keeping the namespace for enum elements open is a priority.
We currently only reserve `index` and `values`.
BUG: https://github.com/dart-lang/language/issues/1511
Fixes language issue #1511, which is a long-standing request,
and should replace a number of alternative implementations
which are based on parsing the `toString()`.
This version has two fields on the shared superclass, the index
and private name, and has a separate `toString` for each `enum` class
which hard-codes that enum's class name.
An earlier version had both `"name"` and `"ClassName.name"` as fields
to be able to reuse the same `toString` method on all enum classes,
but that cost too much for JS compiled code.
Even having just `ClassName.` as a field and then combining inside
`toString` requires more code to create the enum instances.
Instead this version hardcodes the `ClassName.` string once
in the `toString` method, which means each enum class has its own
toString (which can *potentially* be tree-shaken then.)
This still tree-shakes slightly worse than the previous implementation
where every enum class had its own `index` and `_name` fields
independent of each other, which could then be tree-shaken independently.
However, the `index` was already made an interface member with the
addition of the `Enum` interface, so code which accesses `.index`
on something of the `Enum` supertype could prevent tree-shaking of
all enum classes' `index` fields.
Likewise any general access to the "name" of an enum would necessarily
do the same for the name.
This CL makes up for some of that by sharing more implementation
between enum classes.
DartVM AOT CodeSize impact: ~0.15% regression on gallery (little less on big g3 app)
TEST= New tests added to enum_test.dart
Change-Id: Id25334e6c987f470f558de3c141d0e3ff542b020
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/210480
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
William Hesse