Skip to content
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

support some form of fully qualified references in dartdoc documentation #27471

Open
devoncarew opened this issue Oct 3, 2016 · 5 comments
Open
Labels
analyzer-api Issues that impact the public API of the analyzer package area-analyzer Use area-analyzer for Dart analyzer issues, including the analysis server and code completion. P2 A bug or feature request we're likely to work on type-enhancement A request for a change that isn't a bug

Comments

@devoncarew
Copy link
Member

See dart-lang/dartdoc#1153 for more discussion and background.

We'd like to be able to refer to symbols in dartdoc references without having to add imports just for those references. Examples of a fully qualified scheme are [widgets.Draggable] or [package:flutter/widgets Draggable], but I don't think the exact scheme matters for the purposes of fixing this bug.

/cc @scheglov @bwilkerson

@devoncarew devoncarew added the area-analyzer Use area-analyzer for Dart analyzer issues, including the analysis server and code completion. label Oct 3, 2016
@scheglov
Copy link
Contributor

scheglov commented Oct 3, 2016

I'm on the fence about this feature.

On one hand, this is something useful for our users.

OTOH, implementation would require us to look for URIs to import not only in import directives, but also in comments. And these import URIs are special - we don't need full resolution for them. Or we do need, if the referenced element is a field for which type inference should be done. So, it would be as expensive for analysis as adding this libraries are real imports. And we would need to add this dependency into summaries, so we will add a dependency cycle and might get bitten in Bazel :-(

@zoechi
Copy link
Contributor

zoechi commented Oct 3, 2016

@devoncarew why do you think these "inline" imports are better?
Is this to prevent files being imported at runtime that are actually not required or is this just about more convenient syntax?

@devoncarew
Copy link
Member Author

Thanks for the context on the implementation complexity. I would prefer not to make analysis more complex for the sake of this feature.

Are there alternative implementations - compromises in how the references could be used or defined - that wouldn't have negative implementation implications?

@bwilkerson
Copy link
Member

If you want analyzer to be able to resolve the references so that dartdoc can produce links to the referenced entities, then it has to know where the reference is defined, which is equivalent to having an import. So, no, I can't think of any way to get what you want without the overhead.

@bwilkerson bwilkerson added P2 A bug or feature request we're likely to work on type-enhancement A request for a change that isn't a bug labels Oct 3, 2016
@pq
Copy link
Member

pq commented Jun 29, 2018

/cc @jcollins-g

@srawlins srawlins added the analyzer-api Issues that impact the public API of the analyzer package label Jun 17, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
analyzer-api Issues that impact the public API of the analyzer package area-analyzer Use area-analyzer for Dart analyzer issues, including the analysis server and code completion. P2 A bug or feature request we're likely to work on type-enhancement A request for a change that isn't a bug
Projects
None yet
Development

No branches or pull requests

6 participants