Add 'get:' and 'set:' prefixes to getter and setter selectors.
Also revise snapshot serialization of private names to support
private getter and setter names. ast.Name is replaced with
VM-specific PrivateName as private getter/setter names
such as get:_foo are considered public by ast.Name
(as they don't start with '_').
Issue: https://github.com/dart-lang/sdk/issues/61635
Change-Id: I7447cb457aa2463836c8cf6af3d12e1998fe325c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/481441
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
Also:
* Support arguments descriptors.
* Fix order of ClosureCall inputs in local function invocations.
* Fix order of passing arguments in all Dart calls.
* Fix handling of fields in InstanceSerializationCluster.
* Do not compile abstract methods and fields.
* Do not generate initializer functions for fields with trivial
initializers.
* Initialize Code::code_source_map to an empty CodeSourceMap
(in order to avoid failed assertions).
TEST=tools/test.py -n vm-modaot-mac-debug-arm64 language
Issue: https://github.com/dart-lang/sdk/issues/61635
Change-Id: I40ff1b8234c32c41e08f3288a23e4abc173efcfd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/480020
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Change ScopeContext.withLocalScope to pass the created LocalScope to the
callback, and add LocalScope helpers for bulk insertion of declared
elements.
Refactor resolution/scoping visitors to use the provided LocalScope
rather than downcasting nameScope or relying on ad-hoc predeclaration:
- Predeclare local functions, local variables, and pattern variables in the
correct enclosing scope before visiting initializers/bodies, so lexical
lookup binds to loop/local elements consistently (including in implicit
block scopes for control-flow sub-statements).
- Centralize for-loop-parts handling (declarations, identifiers, patterns)
so each part is visited in the required order while installing the right
loop-local bindings.
- Compute and store declared pattern-variable elements directly on the
relevant AST nodes, and update ForEachPartsWithPattern to carry variable
elements (so flow analysis can declare them without extra indirection).
Also ensure metadata on pattern variable declarations and pattern-for
parts is visited in the same scope model as other declarations.
Change-Id: I35d52860b6816196085d79979cda861583c850be
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/482540
Reviewed-by: Johnni Winther <johnniwinther@google.com>
A forwarding stub can have a covariant type parameter while the same
type parameter in its forwarding stub target is non-covariant.
We should still check bounds of such type parameters
(the bound to check is taken from the forwarding stub target).
TEST=tests/language/regress/regress62664_test.dart
Fixes https://github.com/dart-lang/sdk/issues/62664
Change-Id: I86eeb9f8a537c22fb473388f9b17f55084af6366
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/482480
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
Rolls in support for enum consts and record consts, but doesn't
start using them yet.
TEST=pkg/compiler/test/record_use/record_use_test.dart
TEST=pkg/dart2wasm/test/record_use_test.dart
TEST=pkg/vm/test/transformations/record_use_test.dart
Change-Id: Ia161e41e401b051a59976be6225570a6c2dd09ad
Cq-Include-Trybots: luci.dart.try:dart2wasm-asserts-linux-chrome-try,dart2wasm-asserts-minified-linux-d8-try,dart2wasm-linux-chrome-try,dart2wasm-linux-d8-try,dart2wasm-linux-firefox-try,dart2wasm-linux-jscm-chrome-try,dart2wasm-linux-optimized-jsc-try,pkg-linux-debug-try,pkg-linux-release-arm64-try,pkg-linux-release-try,pkg-mac-release-arm64-try,pkg-mac-release-try,pkg-win-release-arm64-try,pkg-win-release-try,dart2js-canary-linux-try,dart2js-hostasserts-linux-d8-try,dart2js-linux-chrome-try,dart2js-linux-firefox-try,dart2js-mac-chrome-try,dart2js-mac-safari-try,dart2js-minified-csp-linux-chrome-try,dart2js-minified-linux-d8-try,dart2js-unit-linux-x64-release-try,dart2js-win-chrome-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/482800
Reviewed-by: Michael Goderbauer <goderbauer@google.com>
Commit-Queue: Daco Harkes <dacoharkes@google.com>
And they may not be extended, implemented and mixed in.
It would be cleaner if we test the static checks with the [cfe]
test expectations. However, those test suites are not set up to
run from a package context, which `@RecordUse` annotations must be.
TEST=pkg/compiler/test/record_use/record_use_test.dart
TEST=pkg/dart2wasm/test/record_use_test.dart
TEST=pkg/vm/test/transformations/record_use_test.dart
Change-Id: Ia4e93a6f25ad4c246503ebf8ece67e7d4bca1410
Cq-Include-Trybots: luci.dart.try:dart2wasm-asserts-linux-chrome-try,dart2wasm-asserts-minified-linux-d8-try,dart2wasm-linux-chrome-try,dart2wasm-linux-d8-try,dart2wasm-linux-firefox-try,dart2wasm-linux-jscm-chrome-try,dart2wasm-linux-optimized-jsc-try,pkg-linux-debug-try,pkg-linux-release-arm64-try,pkg-linux-release-try,pkg-mac-release-arm64-try,pkg-mac-release-try,pkg-win-release-arm64-try,pkg-win-release-try,dart2js-canary-linux-try,dart2js-hostasserts-linux-d8-try,dart2js-linux-chrome-try,dart2js-linux-firefox-try,dart2js-mac-chrome-try,dart2js-mac-safari-try,dart2js-minified-csp-linux-chrome-try,dart2js-minified-linux-d8-try,dart2js-unit-linux-x64-release-try,dart2js-win-chrome-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/482220
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Nate Biggs <natebiggs@google.com>
Reviewed-by: Michael Goderbauer <goderbauer@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
https://dart-review.googlesource.com/c/sdk/+/481782 removed the tracing
of the original instruction for breakpoints. This CL adds it back.
Also increments icount_ before calling TraceInstruction in the dispatch
loop instead of afterwards so that breakpoint/single step tracing can
just use icount_ without adjusting it. In particular, this means tracing
the original instruction at a breakpoint can just use TraceInstruction
instead of duplicating it.
Also, now both the breakpoint instruction and the original instruction
are written to the instruction trace if requested, instead of only the
breakpoint instruction.
TEST=debugging only changes, so manually tested.
Cq-Include-Trybots: luci.dart.try:vm-dyn-linux-debug-x64-try,vm-dyn-mac-debug-arm64-try
Change-Id: I1999f1d9e7ba55b950c508e848ff12db0c8d5cab
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/482320
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Auto-Submit: Tess Strickland <sstrickl@google.com>
Commit-Queue: Tess Strickland <sstrickl@google.com>
If a function doesn't have an effect we can now mark it via
`@pragma('wasm:pure-function')`. We'll then emit this as metadata
in the `binaryen.remove.if.unused` custom section.
This allows `wasm-opt` to remove calls to such functions if the result
of the call isn't used.
For now we mark a few string functions as pure.
Closes https://github.com/dart-lang/sdk/issues/62665
Change-Id: I8d38fb5894fd98248dc4d648d99c8cdcddc271a5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/481802
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Nate Biggs <natebiggs@google.com>
Previously, the mini_ast used for flow analysis testing simulated
prefix increment/decrement operations using a `Write` node with a
null right-hand side. This commit introduces a dedicated `PreIncDec`
node to represent these operations more accurately.
The test "write() permits expression to be null" is removed in favor
of two new tests:
- "preIncDec() stores expressionInfo in the write"
- "preIncDec() demotes to the written type"
These new tests parallel the corresponding tests that already exist
for postIncDec.
Change-Id: I6a6a69646c63ca1c605272d4170eae3729ce90e1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/482560
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This change makes two changes to how flow analysis works for post
increment/decrement operations.
Firstly, in the anaylzer implementation, the check against
`inference_update_4` is removed. Previously, the analyzer called
`FlowAnalysis.postIncDec` when `inference_update_4` was enabled, and
`FlowAnalysis.write` when it was disabled. This was unnecessary, since
that language feature had no effect on the flow analysis of post
increment/decrement. Furthermore, it was a violation of separation of
concerns, because even if that language feature _had_ had an effect on
the flow analysis of post increment/decrement, it would have been the
job of flow analysis to implement that effect, not the
client. Fortunately, `FlowAnalysis.write` happens to have the same
behavior as `FlowAnalysis.postIncDec` when `inference_update_4` is
disabled, so there is no behavioral change; this is purely a clean-up.
Secondly, the return type of `FlowAnalysis.postIncDec` is changed from
`ExpressionInfo?` to `void`, and the calls to `storeExpressionInfo`
are removed from call sites. Previously, `FlowAnalysis.postIncDec`
always returned `null`, so again, there is no behavioral change.
Note that these changes do not affect the front_end in any way, since
it de-sugars `x++` and `x--` to equivalent "let" expressions before
invoking flow analysis. Those let expressions, fortunately, have the
same flow analysis effect as `FlowAnalysis.postIncDec`. Thanks to the
test added in https://dart-review.googlesource.com/c/sdk/+/482342, we
have enough language test coverage to confirm this.
Change-Id: I6a6a6964253394c71e6bc72d801d9044b1b1ae30
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/482541
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Adds a language test and a flow analysis unit test to cover a flow
analysis behavior of post-increment and post-decrement operators that
wasn't previously covered.
The tests verify that the expressions `x++` and `x--` demote `x` in
the same way that `x = x + 1` and `x = x - 1` would. This demotion is
only user-visible if the type of `x` is a user-defined type.
In the process of writing these tests, I noticed that the "mini-AST"
implementation of post-increment (which is used solely for flow
analysis unit testing) was not correct; it presumed that the type read
from the target, the type written to it, and the type of the whole
expression were all the same. This is not correct; the type written to
the target is determined by the return type of the `+` operator. I've
fixed this as part of this CL so that the unit test properly exercises
flow analysis.
I will follow this up with some refactoring of how flow analysis
handles post increment/decrement operations. Landing the test first
allows us to be confident that the refactor won't change the tested
behavior.
Change-Id: I6a6a6964417b48db0c1681c06d7418bd79e96357
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/482342
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This handles the most of the cases I could think of. Please review with
an eye toward catching holes. I also left a couple of questions in the
tests as there are a couple of cases I wasn't sure we wanted to support.
This doesn't handle fields with an initializer, though I think we could.
If you think we ought to handle it before shipping the feature I can either
update this CL or do it in a follow-on.
Change-Id: Ia9ac5d86853bc907fdce10e31f03714eeb89f1af
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/481621
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Tests the following:
- A compile-time error occurs if an assignment to a primary parameter
occurs in the initializing expression of a non-late instance variable.
- A compile-time error occurs if a declaration has a primary constructor
with an initializing formal and no instance variable of the same name.
- Declaring parameters named `_` cannot be declared multiple times in a primary constructor.
- Wildcard variables cannot be referenced in the initializing
expressions of non-late instance variables or in the initializer list of
the body part of the primary constructor.
- Declaring parameters named `_` are allowed. Accessing `_` is valid in
the body part of a primary constructor if there's an instance variable
with the name `_`.
Bug: https://github.com/dart-lang/language/issues/4634, https://github.com/dart-lang/sdk/issues/61687
Change-Id: Id2cb98bd78e31292894610b595174fa682bdc1ae
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/481321
Reviewed-by: Erik Ernst <eernst@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
The customization mechanism provides the following pieces of
functionality:
- Allows access to the package name, the analysis context, the list of
public API libraries, and the set of top level public API elements.
- Allows customizing the logic for deciding which top level elements
to show details about.
- Provides hooks to allow additional code to be executed after setup
and after the initial scan.
This customization mechanism is used when generating
`pkg/analyzer/api.txt` to recognize that any element annotated with
`@AnalyzerPublicApi` should have details shown, even if it is not
exported in any analyzer public library.
The class used to perform customization, `ApiSummaryCustomizer`, is
marked `base` so that we can add additional hooks in the future
without breaking clients.
With this change, the API summary tool no longer has any hard-coded
analyzer-specific functionality.
Change-Id: I6a6a6964fcc626db8e8e387c306fc1ff03fbc0a9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/482442
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
- The dependencies of a class should also include the initializers for its fields. These are used to initialize the class object. And they are not represented in the constructor Initializers list.
- Super gets/sets/invocations should all visit their children as well. These aren't leaf nodes.
Change-Id: I552bc87cf1bbc35b11b0dd7bcbd167b2fa5bcbe7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/481680
Commit-Queue: Nate Biggs <natebiggs@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Changes the logic for deciding whether to output details about a top
level element. Previously, details would be output if the library
containing the element's declaration was in `lib` but not
`lib/src`. This led to a bug: if a top level element was declared in
`lib/src` but exported by an `export` directive in `lib`, no details
would be output, and the API summary would just show `(non-public)`
after the exported name.
This bug was mostly benign because we were working around it with an
analyzer-specific hack: when analyzing the `analyzer` package, top
level elements with an annotation of type `AnalyzerPublicApi` would
have their details output regardless of where they were declared. But
it wasn't completely benign: the tool was failing to output details of
`DartDocumentLinkVisitor` and `DocumentLink` (from
`package:analyzer_plugin`), as well as `PackageBuilder` (from
`package:analyzer_testing`).
The new logic is: details are output if the element appears in the
export namespace of any library in `lib` but not `lib/src`. I've
re-run the API summary tool so the `api.txt` files in
`package:analyzer_plugin` and `package:analyzer_testing` now include
the details they were missing.
The analyzer-specific hack is left in place, though, because there are
some analyzer classes that aren't exported, but still considered part
of the analyzer public API. In a follow-up CL, I will make the API
summary tool extensible so that this analyzer-specific logic can be
injected by the analyzer when generating its `api.txt` file, and it
won't pollute the incipient `api_summary` tool.
Change-Id: I6a6a69641d656caa4f8e6361557c13fa7485e422
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/482440
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Expand ScopeContext into the single place that manages resolver
name-scope transitions, and migrate visitors to use it directly.
ScopeContext now:
- Owns the current name scope and handles push/pop via withScope().
- Provides focused helpers for common resolver scopes:
- withLocalScope(), withInstanceScope(), withExtensionScope()
- withTypeParameterScope() and withTypeParameterList()
- withFormalParameterScope()
- withConstructorInitializerScope() and withPrimaryParameterScope()
- withDocImportScope() for documentation comment resolution
- Renames walkMixinDeclarationScopes() to visitMixinDeclaration() and routes
mixin traversal through the shared helper.
Update ResolutionVisitor, ScopeResolverVisitor, and ReferenceResolver
to:
- Remove temporary routing getters/methods and ad-hoc try/finally scope
management.
- Use the new ScopeContext helpers for consistent scoping across declarations,
function bodies, and DeCo/primary-constructor-related initializer contexts.
- Reduce duplicated scope wiring and keep scope behavior localized for easier
future evolution.
This is reland of https://dart-review.googlesource.com/c/sdk/+/481981 with support for ScopeResolverVisitor.visitAnonymousMethodInvocation, see PS(s).
Change-Id: Ieee6c732872fc32af86710237972cd7397ca54dd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/482365
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Adds the modifiers `abstract`, `base`, `final`, and `interface` to the
API summary output.
This information is an important part of the public API of a package,
because it determines whether a client can:
- Construct an instance of the class,
- Extend the class, or
- Implement the class.
Change-Id: I6a6a6964ba07db1714bc2fcb549cc15230e87058
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/482362
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Fixes two minor bugs with the sorting of members in the API summary
tool:
- The technique for placing getters next to their corresponding
setters was to sort them lexicographically based on
`Element.apiName`, which in the case of setters appends `=`. This
mostly worked, but due to the fact that `=` is between `9` and `A`
in ASCII, it was wrong in a few corner cases. For example, it would
sort `x`, `x=`, `x1`, and `x1=` in the order `x`, `x1`, `x1=`,
`x=`. Fixing this didn't affect any `api.txt` files in practice.
- The technique for sorting constructors also used `Element.apiName`,
which in the case of an unnamed constructor is `new`. This meant
that if a class had both named and unnamed constructors, the unnamed
constructor would not always be sorted before the other
constructors.
The fix for both bugs is to sort by `Element.name` (which does not add
`=` for setters and is the empty string for unnamed constructors), and
then to break ties by explicitly checking whether the element is a
setter.
Change-Id: I6a6a69648fb5915266a9111c5d884531bba4405d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/482361
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
These tests cover all the functionality of the API summary tool.
Note that since the `ApiDescription` constructor requires an
`AnalysisContext`, I added a public `contextCollection` getter to the
`PubPackageResolutionTest` base class.
There are a few loose ends I intend to address in follow-up CLs. They
have been noted in TODO comments:
- Annotate when classes are `abstract`, `final`, or `interface`.
- Move `pub_package_resolution.dart` out of
`package:analyzer_testing/src` (so that when I publish this as a
separate package, that package won't be dependent on private
implementation details of `package:analyzer_testing`).
Change-Id: I6a6a69643064115997f6586ff5161ddf4c9f96ff
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/482360
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This reverts commit e730a62688.
Reason for revert: logical merge conflict with https://dart-review.googlesource.com/c/sdk/+/480840
Original change's description:
> DeCo. Centralize resolver scope helpers in ScopeContext.
>
> Expand ScopeContext into the single place that manages resolver
> name-scope transitions, and migrate visitors to use it directly.
>
> ScopeContext now:
> - Owns the current name scope and handles push/pop via withScope().
> - Provides focused helpers for common resolver scopes:
> - withLocalScope(), withInstanceScope(), withExtensionScope()
> - withTypeParameterScope() and withTypeParameterList()
> - withFormalParameterScope()
> - withConstructorInitializerScope() and withPrimaryParameterScope()
> - withDocImportScope() for documentation comment resolution
> - Renames walkMixinDeclarationScopes() to visitMixinDeclaration() and routes
> mixin traversal through the shared helper.
>
> Update ResolutionVisitor, ScopeResolverVisitor, and ReferenceResolver
> to:
> - Remove temporary routing getters/methods and ad-hoc try/finally scope
> management.
> - Use the new ScopeContext helpers for consistent scoping across declarations,
> function bodies, and DeCo/primary-constructor-related initializer contexts.
> - Reduce duplicated scope wiring and keep scope behavior localized for easier
> future evolution.
>
> Change-Id: I753cccc4ed14b4b7c4f34f9c91f5d00895f84c5f
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/481981
> Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
> Reviewed-by: Paul Berry <paulberry@google.com>
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Change-Id: I3515e2d6dba5a49082a8a0496a283706e4cfd48c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/482441
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Auto-Submit: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Expand ScopeContext into the single place that manages resolver
name-scope transitions, and migrate visitors to use it directly.
ScopeContext now:
- Owns the current name scope and handles push/pop via withScope().
- Provides focused helpers for common resolver scopes:
- withLocalScope(), withInstanceScope(), withExtensionScope()
- withTypeParameterScope() and withTypeParameterList()
- withFormalParameterScope()
- withConstructorInitializerScope() and withPrimaryParameterScope()
- withDocImportScope() for documentation comment resolution
- Renames walkMixinDeclarationScopes() to visitMixinDeclaration() and routes
mixin traversal through the shared helper.
Update ResolutionVisitor, ScopeResolverVisitor, and ReferenceResolver
to:
- Remove temporary routing getters/methods and ad-hoc try/finally scope
management.
- Use the new ScopeContext helpers for consistent scoping across declarations,
function bodies, and DeCo/primary-constructor-related initializer contexts.
- Reduce duplicated scope wiring and keep scope behavior localized for easier
future evolution.
Change-Id: I753cccc4ed14b4b7c4f34f9c91f5d00895f84c5f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/481981
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
This new lint fires when a formal parameter is declared with `var` and
no type annotation.
We're adding this lint to ease the migration for when primary
constructors is enabled. Adding a quick-fix for this lint will come in a
follow-up CL.
Tests:
- Class methods, extension methods, extension type methods, mixin
methods, constructors, setters, functions
- Initializing formals
- Super parameters
- Function typed parameters
- Named parameters, positional parameters, optional parameters, required
parameters,
Bug: https://github.com/dart-lang/sdk/issues/61591
Change-Id: Ib09c87e234cde4be024af0b9d8a1e3e0a371e777
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/481620
Commit-Queue: Kallen Tu <kallentu@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This change splits the file `pkg/analyzer_utilities/lib/tool/api.dart`
into several files:
- `api_description.dart`, which contains the `ApiDescription` class
that does the bulk of the work.
- `extensions.dart`, which contains utility extensions.
- `member_sorting.dart`, which encapsulates information about how to
sort members.
- `node.dart`, which defines the tree data structure that is used to
build the output.
- `unique_namer.dart`, which defines the logic for disambiguating
elements that have the same name.
- `uri_sorting.dart`, which encapsulates information about how to sort
URIs.
- `summarize_package.dart`, which contains the code for driving the
`ApiDescription` class.
This is in preparation for extracting this logic from
`analyzer_utilities` and releasing them as a separate pub package
called `api_summary`, so that they can be used by other
projects. Accordingly, I've placed all of these files in their own
directory, `pkg/analyzer_utilities/lib/src/api_summary`. The files
that will eventually wind up in `package:api_summary/src` are in
`pkg/analyzer_utilities/lib/src/api_summary/src`.
(Under ordinary circumstances it would be strange to have a `src`
directory nested inside another `src` directory, but I believe that in
this case it's justified, since it allows us to see which files will
eventually end up in the public API of the `api_summary` package and
which will not.)
I still want to do some final polishing of the tool before publishing
it as its own package:
- Adding unit tests
- Fixing a few bugs
- Generalizing some behaviors that currently only make sense when
analyzing the `analyzer` package.
I intend to do this polishing in follow-up CLs. Then, once the
`api_summary` package is published, I will import the package into the
SDK and remove all the files in
`pkg/analyzer_utilities/lib/src/api_summary`.
Change-Id: I6a6a6964a5f71a732bbee0bfcdcec9458737d703
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/482101
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Introduce `InternalSuperFormalParameterElement` to unify
analyzer-internal handling of super-formal parameters across base and
substituted element implementations.
This refactor:
- Adds an internal mixin that exposes typed `baseElement`, fragments, and
`superConstructorParameter` accessors.
- Updates `SuperFormalParameterElementImpl` and
`SubstitutedSuperFormalParameterElementImpl` to mix it in, so internal
code can reliably identify super-formal parameters via a single type
check.
- Adjusts constant evaluation to collect implicit super-formal argument
values using the internal mixin and `FormalParameterElementImpl` keys,
ensuring the mapped values align with the super constructor’s base
parameters.
Change-Id: If898ffd2fe24a88f60e5b775ccbd3fe8ff9f7186
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/482060
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Ryan Macnak