Skip to content

Extension reexport doesn't handle name conflicts correctly #2047

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
Tracked by #39049
jcollins-g opened this issue Oct 23, 2019 · 0 comments · Fixed by #2050
Closed
Tracked by #39049

Extension reexport doesn't handle name conflicts correctly #2047

jcollins-g opened this issue Oct 23, 2019 · 0 comments · Fixed by #2050
Assignees
Labels
P1 A high priority bug; for example, a single project is unusable or has many test failures type-bug Incorrect behavior (everything from a crash to more subtle misbehavior)

Comments

@jcollins-g
Copy link
Contributor

jcollins-g commented Oct 23, 2019

-- from @stereotype441

I'm worried this might not do the right thing. Consider files foo.dart and bar.dart, each of which defines a distinct extension called E. Then if we have a library like this:

export 'foo.dart' show E;
export 'bar.dart' hide E;

Then I think both Es will get included in extensionElements, because both of them have a name that matches a name that exists in _exportedNamespace.

The best correct approach I can currently think of is:

  • Expose an analyzer API to allow clients to figure out which elements are actually exported by an ExportElement (e.g. we could expose dartdoc to filter a set of elements via namespace combinators (we could move NamespaceBuilder._applyCombinators to ExportElement and re-name it appropriately)
  • Change this code to iterate through the export elements rather than the exported libraries, so that it can use the newly exposed API to figure out exactly which extensions are shown.

It's ok with me if you want to file an issue and address this in a later PR.

Originally posted by @stereotype441 in #2045

@jcollins-g jcollins-g added P1 A high priority bug; for example, a single project is unusable or has many test failures type-bug Incorrect behavior (everything from a crash to more subtle misbehavior) labels Oct 23, 2019
@jcollins-g jcollins-g self-assigned this Oct 23, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P1 A high priority bug; for example, a single project is unusable or has many test failures type-bug Incorrect behavior (everything from a crash to more subtle misbehavior)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant