Skip to content

rustdoc doesn't document reexports of implementations #1956

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.

Sign up for GitHub

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

Jump to bottom
Closed
brson opened this issue Mar 10, 2012 · 3 comments
Closed

rustdoc doesn't document reexports of implementations #1956

brson opened this issue Mar 10, 2012 · 3 comments
Assignees
@brson
Labels
E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.

Comments

@brson
Copy link
Contributor

brson commented Mar 10, 2012

http://doc.rust-lang.org/doc/core/index.html

This page should list vec_len, reexported from core::vec
@ghost ghost assigned brson Mar 10, 2012
@brson
Copy link
Contributor Author

brson commented Mar 19, 2012

@marijnh As far as I can tell reexported impls don't go in the exp_map. How do I find reexported impls so that I can document them?

@marijnh
Copy link
Contributor

marijnh commented Mar 20, 2012

@brson See the code in metadata::encoder::encode_info_for_mod. The impl_map (maps everwhere!) is used for two things -- recording impls-in-scope for functions and method calls, and recording exported impls visible for mods. That's why it contains a linked list of scopes, but the entries for modules always contain a list of length 1 (I guess an enum would have made sense there).

@brson
Copy link
Contributor Author

brson commented Mar 20, 2012

Fixed by 651aeea. Thanks marijn.

@brson brson closed this as completed Mar 20, 2012
celinval added a commit to celinval/rust-dev that referenced this issue Jun 4, 2024
@celinval @zhassan-aws
Introduce project and stop merging all files generated by the compi…
bfdedb8 
…ler (rust-lang#1956)

This PR is a pre-req for getting a per-harness reachability algorithm. First we need to stop treating all goto generated by the compiler as the same model which is what this PR does.

For that, I introduce the concept of a project, which is basically a container of artifacts produced by the build system. The goal is to abstracts the verification code from the build system we pick. It also provide methods to get artifacts relevant to a harness. Today this method will return the artifact related to the crate where it is contained, but in the future it can be easily modified to be the harness specific goto model.

The only behavioral change in this PR is that we disabled `--gen-c` for `--function` and `--legacy-linker` to simplify the code since all these options are for internal usage or on track to be deleted.

This change also fixes inconsistent / incorrect behaviors. They are the following:

1. Kani is now sound when two or more targets contains harnesses or no mangled functions that have the same name (rust-lang#1974). Note that this is not the case for `--legacy-linker` and `--function` options.
2. `kani` now respects the `--target-dir` argument provided by the customer.
3. `kani` no longer crash when the crate has no harness (rust-lang#1910).

Co-authored-by: Zyad Hassan <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@brson brson

Labels
E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@marijnh @brson