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>
Previously, the FfiCode constructor allowed the error type to be
overridden, but no use of that constructor actually took advantage of
it.
Hardcoding the type of all FFI error codes makes the implementation of
error codes more uniform, which helps pave the way for code
generation.
If in the future, we decide that we actually need some FFI error codes
to have different error types than others, we can always add the
functionality back in.
Change-Id: I5061281089aeba0185fd8ebaa08a82482e91f2ca
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/214070
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
* Fail test.py if an invalid named configuration is used.
Cq-Include-Trybots: luci.dart.try:vm-ffi-android-product-arm64c-try
Change-Id: Ib700511a639ee39fd58441dd6fee8bd6dad8c2e5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/214040
Reviewed-by: William Hesse <whesse@google.com>
Fixes https://github.com/dart-lang/sdk/issues/47211
Much of this change is about decision-making based on the _type_ of the
function in a FunctionReference, or the receiver of that function, in the
case of prefixed identifiers or property access.
Previously, there was a rule that only direct references to functions
(top-level, local, and method) could be torn off and type-instantiated.
That rule has been reversed (#1812), so a lot of unraveling has to be
done here.
`e.call<...>` is now legal for _any_ generic function-typed expression
`e`, which certainly may be an expression without a staticElement.
Additionally, `e<...>` is now legal for _any_ generic function-typed
expression `e`.
Because we no longer resolve PropertyAccess piecemeal, we no longer
report UNDEFINED_IDENTIFIER or UNDEFINED_PREFIXED_ELEMENT etc before
deciding to check if a tearoff is being made on a function-typed
element. The unfortunate side-effect here is some redundant
error-reporting. :( I've left TODOs.
Change-Id: I62106332e39d528cbd7cdfa5ec831dc56b394b52
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/213800
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
- Use `{}` syntax for Maps and Sets
- Remove type arguments on right side of initializations with same
type arguments.
- A few cases of replacing conditional code with `??`/`??=`.
Change-Id: I1b58a109b1f8ea8458f37a2de256ffb3dc9956b1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/213853
Reviewed-by: Joshua Litt <joshualitt@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
The error code text is:
The setter '{0}' is private and can't be accessed outside of the
library that declares it.
So when instantiating this error we should only provide a single
argument. Previously we were providing a second argument that was the
name of the type.
Change-Id: I952dec86f079b9e17e071d37895c3b38c715cf4f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/213826
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Previously, if a CFE error contained a placeholder (such as
`#string`), that wasn't converted to the equivalent analyzer
placeholder, which meant that analyzer error reporting logic needed to
know whether the error being reported came from the CFE or the
analyzer in order to report the error correctly, otherwise the
placeholder text would just show up verbatim in the analyzer output.
Change-Id: If875de3a1a80048700b0edf458377c5fc87a15d0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/213281
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
The hint code text is:
The declaration '{0}' is annotated with 'visibleForOverriding'. As
'{0}' is not an interface member that could be overriden, the
annotation is meaningless.
So when instantiating this error we should only provide a single
argument. Previously we were providing a second argument that was the
name of the annotation; this is unnecessary because the error message
already mentions the annotation name ('visibleForOverriding').
Change-Id: I022af6914668ad6232005237619b3ab9a5d7a589
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/213825
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
It was incorrectly marked as having them. Attempting to navigate to docs
opens the correct page but there's no docs to open to so it leaves the
page scrolled to the top.
Change-Id: I862fa215ee59e8aa1200a7e33186e91528b8ef19
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/213840
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Konstantin Shcheglov