[ffigen] Config update part 4: include visitor - #3530
Conversation
Package publishingIf you have publishing permissions, you can use the links below to publish the changes after merging this PR.
Documentation at https://github.com/dart-lang/ecosystem/wiki/Publishing-automation. |
PR HealthChangelog Entry ✔️
Changes to files need to be accounted for in their respective changelogs. This check can be disabled by tagging the PR with API leaks ✔️The following packages contain symbols visible in the public API, but not exported by the library. Export these symbols or remove them from your publicly visible API.
This check can be disabled by tagging the PR with Breaking changes ✔️
This check can be disabled by tagging the PR with |
| enums: const Enums(silenceWarning: true), | ||
| visitors: [ | ||
| Visitor( | ||
| visitFunc: (node) => node.isIncluded = { |
There was a problem hiding this comment.
nit: since it's a visitor already, would make make sense to drop "visit" and have func: and struct: to make it more concise?
| /// Contains typealias for function type if [exposeFunctionTypedefs] is true. | ||
| Typealias? _exposedFunctionTypealias; | ||
|
|
||
| bool isIncluded = false; |
There was a problem hiding this comment.
Could you add a description to the PR which things are by default included and excluded?
E.g. toplevel things are by default excluded? Transitive things are by default opaque? And members by default included?
| visitors: [ | ||
| Visitor( | ||
| visitFunc: (node) => | ||
| node.isIncluded = shouldIncludeNode('functionDecl', node), |
There was a problem hiding this comment.
Nit: this would possibly more readable if shouldIncludeNode was called stableRandomInclude or something. Then it's immediately clear.
Migrate all
.includeand.includeMemberconfig elements to.isIncludedAST fields. For the most part this is straightforward: add anisIncludedfield to the internal AST nodes, expose it in the public AST, and replace the config callbacks inApplyConfigFiltersVisitationwith this field.It becomes a little fiddly because we have to pick a single stage in the processing pipeline to run all the user's visitors. After a lot of playing around I eventually found a setup that preserves the status quo behaviour of the YAML configs (see parser.dart). In hindsight it's a pretty obvious place to put it: after
CopyMethodsFromSuperTypesVisitationetc, so that the renaming/filtering sees the full AST, and just beforeApplyConfigFiltersVisitationwhich consumes.isIncluded.Fixed a minor bug where
FindTransitiveDepsVisitation.transitivesdidn't included all the members of the initial search set. This wasn't a problem for the internal visitors, because they follow all of the links of the internal AST. But the user visitors only follow a few direct member links (eg interface -> method -> param), soallBindingsreally does need to contain all the bindings, if it's going to be the set that the user visitors iterate over.Also, deleted a bunch of subconfigs that are now empty, and migrated all the existing configs in the monorepo.
I think it would make sense to refactor how
Constants work, so that I don't have to expose them in the config AST, but I'll do that in a follow up to keep this PR simple.