Migrate hand-rolled _writeXxxFragment helpers to the shared _writeTemplateFragment. This eliminates duplicated serialization logic (ID / name / offset / modifiers), shrinks the code base, and makes it easier to add new fragment types without boiler-plate.
Removed flags from `bundle_reader` and `bundle_writer`, will remove flag classes in the future as they will be replaced with reading/writing modifiers.
Change-Id: I79aabd1e94bfa831d6718bb2889a6a00e6561112
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/437102
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Replace eight bespoke implementations for reading fragments with the existing `_readTemplateFragment()` method.
This enforces the consistent use of the template method design pattern, reduces code duplication, and makes future maintenance easier.
Change-Id: If213b146e4b055523432c6d12f36994cac8f38c1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/436820
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Work towards #60635
In this change, we rework the AnalysisErrorListener deprecation to
better support users who have their own class that implements
AnalysisErrorListener. This change introduces a sealed supertype,
DiagnosticOrErrorListener, with the old implementation,
AnalysisErrorListener, and the new implementation, DiagnosticListener,
as its sole direct subclasses. Users who have implemented
AnalysisErrorListener should be able to instead implement
DiagnosticListener, and their class is an acceptable instance of
DiagnosticOrErrorListener, wherever that is needed.
In a breaking change we can drop AnalysisErrorListener and deprecate
DiagnosticOrErrorListener, and in the next breaking change, we can drop
DiagnosticOrErrorListener.
For reference, see the first API difference when deprecating AnalysisErrorListener and introducing DiagnosticListener: https://github.com/dart-lang/sdk/commit/903d77cc8229972a424941dcb7b7b79741e833eb#diff-dec15868961d7eadcd009f49d129bebcdb747aaa8dbfde5f5a08884e0cf11e32
Change-Id: I3ccf11d54b41fbca98d020d89978d250c16b4c04
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/436480
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Use ConstructorElementMixin2 as its type.
All resolution is always base on element, so here we stop using fragments, and stop storing this information in fragments.
Change-Id: Ide073eb3f5efd3fa1afaac855beb092c114e304f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/436162
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
It is getter / setter elements that know that they form a
PropertyInducingElement, and the other way around,
PropertyInducingElement that has getter and setter. Fragments OTOH, just
dangle from the elements.
Change-Id: Ide8ece5cb318c75093b0173c661b01f564d1a55a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/435746
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This request is useful only for elements. We can create a synthetic
element, and by necessity a fragment for it, but we never create a
synthetic fragment just by itself, for a non-synthetic element.
Change-Id: Ia8fee5e12e7b2c915c72276a402e164b9b30dc1e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/436080
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Replace `getInheritedMap()` with v2 version.
Remove `getMember()`, operations should go thought elements, not types.
Remove `getMember2()`.
Rename v2 `getMember4()` into `getMember()`.
A few internal methods are duplicated for now, will be de-duplicated
when migration of InheritanceManager3 is finished. For now I'd like to
do smaller steps than migrating it fully.
Change-Id: Ib5d9d28e91d77330e41480fcb7176f93d867728a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/435663
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
the nullability of `_indexOfReference()` formal parameter. It turns out that no code paths
ever pass null to it.
Also reuse _writeVariableGetterSetterLinking() for top-level variables.
Change-Id: Ia031ca5097fadaa28ea52a47fb18ebbc06d76c4e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/435722
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
This change reworks
`MemberDuplicateDefinitionVerifier._checkConflictingConstructorAndStatic`
and `MemberDuplicateDefinitionVerifier._checkDuplicateIdentifier` into
a form that is easier to reason about and has slightly faster
performance (measured by instruction count).
In the previous design, two maps were maintained for each scope in
which getters and setters might appear:
- one called `getterScope`, which (confusingly) held getters, setters,
and method declarations,
- and one called `setterScope` which only held setters.
This was difficult to reason about. In particular, it had a
longstanding bug that was only recently fixed (see
https://dart-review.googlesource.com/c/sdk/+/434061): if a setter was
encountered first, it was stored in `getterScope`, but if a getter was
encountered next, it was necessary to move the setter to `setterScope`
in order to store the getter in `getterScope`.
It was also inefficient, since in many cases, two map lookups were
needed in order to check for both getter and setter conflicts.
In the new design, there is a single map, whose values point to either
a `_ScopeEntryFragment` (in the case where just one declaration of the
given name has been seen) or a `_ScopeEntryGetterSetterPair` (in the
case where both a getter and a setter have been seen).
The new design has modestly better performance when measured by
front_end/tool/benchmarker.dart:
Comparing snapshot #1 (before.aot) with snapshot #2 (after.aot)
instructions:u: -0.0192% +/- 0.0131% (-6291379.67 +/- 4292101.91) (32692292436.33 -> 32686001056.67)
Change-Id: Ia6675fa4d3579779e6066db3760d2cc38a2c859e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/435602
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Use-case: I have 20+ folders from the sdk that I have open
(front_end, _fe_analyzer_shared, vm, analyzer, analysis_server etc) and
before this CL that meant I had 20+ contexts, despite them having
`resolution: workspace` and being specified in the roots pubspec.yaml
under `workspace`. Opening, for instance, `pkg` directly would
successfully give me only 1 context, but also include lots of stuff I
don't want to clutter neither my screen nor my mind.
This CL merges such folders as possible meaning I with this CL only have
1 context.
* If not using the workspace resolution this should change nothing.
* If opening only the root of a workspace this should change nothing.
* If opening a sub folder that itself isn't a package (say `pkg` in the
sdk) this should change nothing.
Change-Id: Ia38fa6636b02fa95ed274ebf72d424cae7d4da66
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/434802
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Jens Johansen