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

add option of outputting doc attributes to crates + a doc fetching tool #6160

Closed
thestinger opened this issue May 1, 2013 · 5 comments
Closed

Comments

@thestinger
Copy link
Contributor

Similar to Python's pydoc tool, it should just take a path and resolve it to the correct docstring. The REPL could also take advantage of this with a :help meta-command.

@pnkfelix
Copy link
Member

The word "path" in the description could refer to a path on the filesystem denoting a whole crate (i.e. one provides the library file for the crate to the tool), or "path" could refer to a path in a Rust program, denoting some item within a crate. (It could also refer to some combination of the two notions, but I will leave that possibility aside.)

Both interpretations sound potentially useful. I suspect only the latter interpretation is consistent with your use-case of putting this into a REPL :help meta-command.

In the former interpretation, I imagine the docstring extractor would just be another command-line utility program.

In the latter interpretation, the docstring extractor sounds like it would have to be some sort of operation one expresses within Rust programs. (It is not quite a reflection facility, since it is only extracting statically available meta-data, not runtime values.)

Regarding the latter interpretation, I am a little concerned about these sentences from the Rust manual:

Every item has a canonical path within its crate, but the path naming an item is only meaningful within a given
crate. There is no global namespace across crates; an item's canonical path merely identifies it within the crate.

This implies to me that one would want to resolve a path with respect to a particular crate (provided as an additional argument) when doing doc-string extraction; but that contradicts the interface from the first sentence of the description. (That, or implicitly use the current crate as the basis for the resolution; I cannot tell if always using the current crate would suffice for the cases that thestinger is anticipating.)

@thestinger Would you mind elaborating a little bit more about which of the above cases you were asking for? It will help me determine where this falls in our milestone scheme.

@emberian
Copy link
Member

docstrings can be fetched from the JSON output of rustdoc_ng, but if the repl is already linking to the crates, it can just look for the attribute directly (though it will need to do a bit of a dance to get the item from the AST). untagging rustdoc.

@thestinger
Copy link
Contributor Author

(accidentally marked this bug for closure, ignore the mentions here - has been amended)

@steveklabnik
Copy link
Member

I wonder what a Cargo subcommand for this would be like.

@steveklabnik
Copy link
Member

I'm pulling a massive triage effort to get us ready for 1.0. As part of this, I'm moving stuff that's wishlist-like to the RFCs repo, as that's where major new things should get discussed/prioritized.

This issue has been moved to the RFCs repo: rust-lang/rfcs#650

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants