Sanitizers can pickup configuration and suppressions via
special symbols in the binary (e.g. __*_default_suppressions and
__*_default_options). We have a bunch of stale files in the
buildroot which showed how to do it, but none of these were
actually used by the build process.
Update our BUILDCONFIG.gn to actually link this code into
the binaries and clean it up leaving behind only one relevant
suppression for TSAN.
Additionally fix libplatform targets - libdart_platform_no_tsan was
accidentally disabling TSAN for the whole libplatform by adding
no_tsan_config into public_configs instead of extra_configs.
This is needed to unblock landing https://dart-review.googlesource.com/c/sdk/+/444983
TEST=manually with the referenced CL to verify that suppressions work
Cq-Include-Trybots: luci.dart.try:vm-tsan-linux-release-x64-try,vm-tsan-linux-release-arm64-try
Change-Id: Id4e8a5b89c665cf5d89b18c4f5881ef31c3c9396
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/445941
Commit-Queue: Slava Egorov <vegorov@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Introduce the internal `analyzer_element_model_tracking` lint to enforce
explicit tracking annotations on analyzer element-model members. This
codifies how each member contributes to IDs, dependency tracking, and
incremental analysis.
Rule behavior (applies to classes annotated with `@elementClass`):
- Public instance **fields** must be annotated with
`@trackedIncludedInId`.
- Public instance **getters/methods** (non-abstract, non-void) must have
exactly one of:
`@trackedDirectly`, `@trackedDirectlyExpensive`,
`@trackedDirectlyOpaque`, `@trackedIncludedInId`, or
`@trackedIndirectly`.
- Flags invalid annotations on ineligible members (constructors, setters,
static or private members).
- Reports when more than one tracking annotation is present.
- Reports when a required annotation is missing.
Wire-up:
- Add lint codes and names:
- `analyzer_element_model_tracking_bad`
- `analyzer_element_model_tracking_more_than_one`
- `analyzer_element_model_tracking_zero`
- Mark these as `noFix` in error-fix status and enable the rule in
`analysis_options.yaml`.
- Register the rule in the linter.
Model updates:
- Annotate many members in `element.dart` to reflect their tracking
category (e.g. `@trackedIncludedInId` for identity-affecting members;
`@trackedDirectlyExpensive` for lazily computed collections).
- For opaque surfaces where precise tracking is impractical (e.g.
`documentationComment`, `nonSynthetic`, `session`, member lookups,
ancestor queries, `visitChildren`), record usage via
`globalResultRequirements?.recordOpaqueApiUse(...)`.
Why:
- Makes dependency/ID semantics explicit and reviewable.
- Improves correctness of incremental and cache invalidation behavior.
- Establishes a foundation for refining precision over time without
regressions.
Scope:
- Internal only; no public API changes.
Change-Id: Id2beaf5ead35b8a361bc1b7688ccb5b5a74afe88
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/446140
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
This CL enables the new literate API for reporting analyzer
diagnostics that was introduced in
https://dart-review.googlesource.com/c/sdk/+/445803.
The two CLs are separated for easier code review:
- https://dart-review.googlesource.com/c/sdk/+/445803 introduces the
necessary infrastructure classes and modifies the code generator,
but all code generator changes are initially disabled using the flag
`literateApiEnabled`.
- This CL flips the `literateApiEnabled` to `true`, regenerates the
generated code, and makes trivial adjustments to imports necessary
to support the newly generated code.
In follow-up CLs, I will transition the analyzer over to reporting
errors using the new API.
Change-Id: I6a6a69647946f19a370724dbd6f36e02ed0f1d61
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/445783
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Previously, the generated files containing definitions of diagnostic
messages were not sorted. This didn't cause a failure in
`verify_sorted_test.dart` because the definitions of diagnostic
messages were all static constant fields, and member sorting ignores
fields.
However, a follow-up CL will be introducing static methods to
implement the new `.withArguments()` functionality for error codes
that take arguments, and these will need to be sorted. So to prepare
for that, this CL modifies the code generator so that its output is
already sorted.
Change-Id: I6a6a6964c476d8a7b5841860998c50b01e592942
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/446120
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This change introduces a new literate API for reporting analyzer
diagnostics. The new API looks like this:
diagnosticReporter.reportError(
diagnosticCode
.withArguments(...) // omitted if diagnostic takes no arguments
.withContextMessages(contextMessages) // may be omitted
.at(astNode),
);
For comparison, the old API looks like this:
diagnosticReporter.atNode(
astNode,
diagnosticCode,
arguments: [...], // omitted if diagnostic takes no arguments
contextMessages: contextMessages, // may be omitted
);
For the moment, this new API is internal to the analyzer; it is not
exposed through the analyzer public API. This is to give us time to
try it out and make changes if necessary before we have to commit to
it.
The advantages of the new API are:
- Better static type checking: with the old API, if we accidentally
forgot to supply arguments to a diagnostic code that required them,
or vice versa, or supplied the wrong number of arguments, the
mistake would not be caught until runtime. If we accidentally
supplied arguments of the wrong type, the mistake would not even be
caught at runtime. With the new API, any of these mistakes will lead
to a compile-time error.
- Better code completion support: with the old API, if we can't
remember whether a diagnostic code requires arguments, we have to
look it up. With the new API, we can type the diagnostic code
followed by `.`, and completions will be offered for either
`.withArguments` (if arguments are required) or
`.withContextMessages` and `.at` (if no arguments are
required). Furthermore, while typing inside the parentheses after
`.withArguments`, completion will offer the names of the required
arguments.
To allow for a gradual transition to the new API, the old API is still
supported. To make this possible, a new sealed class `Reportable` is
introduced, to act as the parameter type for
`DiagnosticReporter.reportError`. It has two derived classes:
- The existing `Diagnostic` class (which was the old parameter type
for `DiagnosticReporter.reportError`)
- A new `LocatedDiagnostic` class (which is the return type of the new
literate `at` method).
The difference between these two classes is that the `Diagnostic`
class has already had its arguments formatted and disambiguated using
`convertTypeNames`, whereas the `LocatedDiagnostic` class hasn't.
The only change to the analyzer public API for now is the introduction
of `Reportable` and the change to the type signature of
`DiagnosticReporter.reportError`. (It would have been hard to avoid
making this public API change, since the method method
`DiagnosticReporter.reportError` is already exposed publically).
To make code review easier, this CL just introduces the necessary
infrastructure to allow a diagnostic code to start supporting the new
literate API, but doesn't make the necessary modifications to any
diagnostic codes to actually support it. In a follow-up CL, I will
flip the flag `literateApiEnabled`, which will change the generated
code and cause the new literate API to be supported.
In follow-up CLs after that, I will transition the analyzer over to
reporting errors using the new API.
Change-Id: I6a6a696478fdd74803c6215c64ec68626819dd95
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/445803
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
In a follow-up CL, I plan to add an extension on `DiagnosticReporter`
that's not exposed through the analyzer public API, so that we can try
out the analyzer's new literate API for diagnostic reporting without
exposing it to analyzer clients yet. The extension will need to be in
the same library as `DiagnosticReporter` (so that it can access a
private method), so in order to avoid exposing the extension through
the analyzer public API, that library will need to be in `src/`.
From the point of view of analyzer clients, this change is a no-op;
the `DiagnosticReporter` class is still available from
`package:analyzer/error/listener.dart` by way of an export directive.
Change-Id: I6a6a696426f43ee57789b8a7ec1c36bc0b8680ef
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/446100
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This allows us to write enums in the mock SDK (which is currently broken). This will allow me to land such an enum in the SDK, in
https://dart-review.googlesource.com/c/sdk/+/445403.
This diverges from the actual Dart SDK implementation of the Enum class
and the _Enum class. I think this is an acceptable divergence; these
classes hardly ever change, and the changes will be easy to follow
when they come, however many months or years from now.
Change-Id: Ia6ff3803415af8c251dbee330a218f2618395cc4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/446141
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Move class-related flags off fragments and compute them directly on
`ClassElementImpl`. This reduces coupling to fragments and avoids
duplicated logic.
Changes:
- Compute `isConstructable` as `!isSealed && !isAbstract` instead of
delegating to `_firstFragment`.
- Compute `isExhaustive` as `isSealed`.
- Remove `hasGenerativeConstConstructor`, `isConstructable`, and
`isExhaustive` getters from `ClassFragmentImpl`.
- In constant verifier, resolve the enclosing class via
`container.declaredFragment!.element` and check `ClassElementImpl`
rather than fragment types.
Why:
- Centralizes flag computation on the element, making semantics clearer.
- Decreases fragment dependencies and maintenance surface.
Change-Id: I4b7153a4a55037e6dc12e18a32161a3472902eeb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/446008
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Strengthen the `session` type on `InterfaceElementImpl` from nullable
`AnalysisSession?` to concrete `AnalysisSessionImpl` and route it
through `library.session`. This reflects the actual runtime type,
eliminates downcasts, and makes the API non-nullable.
Key changes:
- `InterfaceElementImpl.session` now returns `AnalysisSessionImpl`.
- Replaced usages of `(session as AnalysisSessionImpl)` with direct `session.inheritanceManager...` calls (e.g., inherited/interface member lookups and overrides).
- Removed a generic nullable `session` getter that delegated to an enclosing fragment, and dropped redundant fragment-level overrides where the library already provides the session.
Why:
- Improves type safety and clarity by matching the concrete session type.
- Removes unnecessary nullability and casting boilerplate.
- Centralizes the source of truth for the session via the owning library.
Change-Id: I2f8e045c34218e9e10caa794b830219326c7da1d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/446006
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Compute `InterfaceElementImpl.hasNonFinalField` once during linking and
persist it in summaries for classes and mixins. This replaces the
previous on-demand, tracked getter with a stored boolean initialized via
a recursive walk over the superclass and mixin chain.
Key changes:
- Add `bool hasNonFinalField` to `InterfaceElementImpl`.
- Compute the value in `link.dart::_computeHasNonFinalField()` after
`_resolveTypes()` and before `_setDefaultSupertypes()`, memoizing to
avoid recomputation.
- Serialize/deserialize the value in bundle writer/reader for class and
mixin elements.
- Remove the expensive getter and its requirement recording.
- Bump `DATA_VERSION` to 525.
Why:
- Avoid repeatedly traversing hierarchies at query time.
- Make the property available across library boundaries via summaries.
- Reduce analysis overhead for checks that depend on field mutability
(e.g., const constructor eligibility).
Impact:
- No intended behavioral change; the result matches the prior logic:
true if any instance, non-const, non-static, non-synthetic field is
declared in the class, its supertypes, or applied mixins.
- Older summaries are invalidated by the version bump.
Change-Id: I2db038341d5a1d9c2d039bc73db9b6bd1e566056
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/446002
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
This embeds the handling of null-aware access into the regular internal nodes. This also avoids some of the lowerings performed during body building.
This removes the now unused NullAwarePropertyGet and NullAwarePropertySet. NullAwareMethodInvocation will be removed latter because it is still used in other lowerings.
Change-Id: I88f3d67919cc9dadf9d16dcef4a474de90780260
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/445940
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Fixes https://github.com/dart-lang/sdk/issues/60644
Previously, we made no special case for JSBoxedDartObjects, so isA
would always return true for any object (as JSBoxedDartObject contains
an @JS('Object') annotation). This is not obvious however, and it's
much more useful to check that the value is a result of a previous
`toJSBox` call. Documentation is updated/cleaned up to make note of
the various exceptions in `isA`.
CoreLibraryReviewExempt: Web-only library.
Change-Id: Ibd8873d3f862f4c950101f5f049327a1aa5c7bf2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/445522
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
Unifies extension type cycle breaking with the existing
`breakInterfaceCycles()` flow used for other elements and removes the
bespoke walker in `summary2/extension_type.dart`. This consolidates the
logic and ensures consistent behavior across element kinds.
Key changes:
- Move `hasImplementsSelfReference` and
`hasRepresentationSelfReference` from fragments to
`ExtensionTypeElementImpl`. Flags are now owned and serialized by the
element.
- Update summary I/O: writer emits and reader consumes the flags at the
element level; fragment-level reads/writes are removed.
- Adjust `ErrorVerifier` to read flags via `fragment.element`.
- Handle extension types inside `interface_cycles.dart`: on an SCC,
mark `hasImplementsSelfReference` and replace `interfaces` with
`Object` or `Object?` depending on the representation’s nullability.
- Bump `DATA_VERSION` to 524 due to summary layout changes.
Why:
- Eliminates duplicate, divergent cycle-breaking logic for extension
types.
- Clarifies ownership of self-reference state and simplifies
serialization.
- Produces consistent diagnostics and interface normalization across
element kinds.
Impact:
- Requires a format bump; older summaries are invalidated as intended.
- Fragment-level self-reference bits are removed in favor of
element-level flags.
Change-Id: Ifabb0acb2ce60353bbfe10ee5877c0c66cee5202
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/445961
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
This change refactors the `_attachFinally` method in `_FlowAnalysisImpl`
to better align with the flow analysis specification.
Notable changes include:
- Moving `attachFinally` to the `FlowAnalysisImpl` class rather than
implicitly passing the `afterTry` model as `this`. This makes the
arguments to `attachFinally` match those in the spec.
- Extracting the handling of a single variable to a separate function,
`attachFinallyV`, to align with the spec.
- Renaming local variables to match variable names in the spec.
- Adding comments that refer to specific spec language.
- Adding parenthetical "OPTIMIZATION:" comments to document
differences between the implementation and spec that are for the
purpose of efficiency and don't affect behavior.
- Adding parenthetical "UNSPECIFIED:" comments to documented
differences between the implementaiton and spec that reflect flow
analysis features that haven't been documented yet.
- Adding comments that directly reference the `attachFinally` and
`attachFinallyV` sections of the specification.
- Reordering logic to more closely follow the structure of the
specification.
This is a pure refactoring and does not change the behavior of flow
analysis.
Change-Id: I6a6a6964bd76b87102facf4251b195e5604c7c32
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/445780
Reviewed-by: Erik Ernst <eernst@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Note: Const locals are still off for VM aot and dart2js for the entry
points I've found in an attempt to retain the old behaviour there.
It might be better if those targets could remove such locals in a
whole-world analysis instead.
* Keep const locals by default (except as noted above). Update the
verifier to accept that. For the platforms this has increased the
size by at most 6584 bytes. With this the VM will pass in any const
locals as it does normal locals, but as the variable is never
captured it will never pass a const local defined in a method when
inside a local function in that method.
* Change the dart scope calculation(s) to return the found variables
instead of just the types of the found variables.
* When the incremental compilers expression compilation - via the dart
scope calculation - finds a const local that it wasn't told about, it
will pass it on as an extra variable that it knows about, allowing
for evaluating const locals in the case not covered by the first
bullet.
With luck this can in future CLs be extended to know about other
variables that we're not told about, allowing to give a message saying
something like
"yes, we know what 'foo' is, but you can't currently use it" as wanted
in for instance https://github.com/dart-lang/sdk/issues/60316 and
https://github.com/dart-lang/sdk/issues/53996.
Tested: Existing tests for existing functionality; new tests for the new
Change-Id: I1ec24350273e6f81574bb2888f6bf46e3b8b1b47
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/445461
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Skip the `JSSymbol` indirection and use an `externref` for the `Symbol`
object directly.
With the `JSSymbol` the indirection cannot be eliminated by inlining,
because we have to check whether the `JSSymbol` static object is
allocated first, and then access its `externref` field.
When using an `externref` directly we still check whether the static
field is initialized, but if it is we directly access the `extenref`,
without going through `JSSymbol`.
Change-Id: I9feae319c34fc5a3f83c0f5ba3767454a1f94566
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/445680
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Ömer Ağacan <omersa@google.com>
This CL changes the diagnostic code generator for lint diagnostic
codes to consistently use `LinterLintCode` as the static type of the
generated constants, instead of the superclass, `LintCode`.
This change makes the code generation more consistent between the
analyzer and the linter, which will pave the way for further
improvements to diagnostic code generation that I have planned in
follow-up CLs.
Change-Id: I6a6a6964f5b533eb722066195d83bd8379dbbd43
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/445781
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This change adjusts the code generation for analyzer diagnostic
messages so that parameter type descriptions use the analyzer type
name rather than the generic type name used in `messages.yaml`.
The only difference today is that where `messages.yaml` uses `Type`,
the analyzer uses `DartType`.
Change-Id: I6a6a6964d402bc93e2bf08c66f80aa5bc3af7f1e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/445802
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Previously, internal analyzer logic that accessed element properties
would would require `globalResultRequirements.includedInId()` wrapper to
avoid inadvertently trigger opaque API usage tracking. This created
unnecessary overhead for internal operations.
This change introduces a new internal `_firstFragment` getter on
`ElementImpl` and its subclasses. Element properties that are used
internally are updated to access data directly through `_firstFragment`,
bypassing the API tracking wrapper.
The existing `firstFragment` field in most element implementations has
been renamed to `_firstFragment`, and a new public getter is provided to
maintain the public API.
As part of this refactoring, `MultiplyDefinedFragmentImpl` is also
updated to extend `FragmentImpl` for consistency.
Change-Id: I391d64fa3dd24451acefe37d8bc100fdfe88be4a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/445782
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Previously, diagnostic codes were generated into libraries. This led
to a proliferation of imports of those generated libraries throughout
the analyzer and analysis server codebases, since the analysis server
didn't know that it should suggest adding imports of the correspinding
non-generated libraries instead.
I tried to fix that problem by marking each generated diagnostic code
library as deprecated, and ignoring the deprecation warning at the
site where the corresponding non-generated file imports it. But this
led to a different problem: it prevented code completion from
suggesting elements that came from the generated libraries. In my work
toward replacing the analyzer's error reporting API with a more
literate API (e.g. `reportError(errorCode.withArguments(...).at(...))`),
I've discovered that the lack of code completion makes the more
literate API much harder to use.
This CL changes the code generator so that diagnostic codes are
generated into part files. This neatly prevents unintentional imports
of the generated files without having to do any tricks with
deprecation.
A side benefit of this change is that the code generators no longer
need complex logic to determine which `import` directives to generate,
since the import directives live in the non-code-generated parent
library.
Note that in the past, the analyzer code base has heavily discouraged
the use of part files. I think they are justified in this case,
because the files are generated; if it were not for the desire to code
generate these files, we would fold them straight into the libraries
they are parts of.
Change-Id: I6a6a6964a375ee81f9580b354766bd041c83b3cd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/445480
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Nate Biggs <natebiggs@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Remove `TypeParameterizedFragmentMixin` and inline its functionality
directly into the classes that were using it. This refactoring
simplifies the class hierarchy and makes the code easier to follow by
co-locating the implementation with its usage.
The mixin's implementation has been moved into the following classes:
* `ExecutableFragmentImpl`
* `GenericFunctionTypeFragmentImpl`
* `InstanceFragmentImpl`
* `TypeAliasFragmentImpl`
This change also simplifies the `isSimplyBounded` getter in several
related classes to return `true` directly, removing unnecessary
delegation and ensuring consistent behavior.
Change-Id: Ia6bb3f5784ba6a32693a42067adbf1622b8bb871
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/445621
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
The `typeErasure`, `primaryConstructor`, and `representation` fields are
properties of the extension type as a whole, not of any individual
declaration fragment.
This commit moves `typeErasure` from `ExtensionTypeFragmentImpl` to
`ExtensionTypeElementImpl` to better align the element model with this
concept.
As part of this refactoring, the `primaryConstructor` and
`representation` getters on `ExtensionTypeFragment` are now deprecated.
Clients should access these properties directly from the
`ExtensionTypeElement`, which serves as the single source of truth. All
internal call sites have been updated accordingly.
Change-Id: I359572c6f7fe1d562fadfb60873a6e34aed0e5ee
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/445580
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
The `_writeElementList` helper in the element text test utility included
complex logic to handle element types that lack a standard
`enclosingElement`. This special casing for `LibraryImport`,
`LibraryExport` (which are not elements at all now), and `PrefixElement`
made the function fragile.
This change removes the conditional logic and tightens the function's
signature to only accept `ElementImpl` (so it cannot be
`SubstitutedXyz`) subtypes. As a result, the call site for `prefixes` is
updated to use the more general `_writeList` function, leaving
`_writeElementList` with the single responsibility of verifying the
`enclosingElement` for applicable types.
Change-Id: I436a863a59bb0394556002bd720c363eacea826b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/445620
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Vyacheslav Egorov