d1fa49b2e6
This allows the public `rustdoc-types` crate to expose this feature easily and allows consumers of the crate to get the performance advantages from doing so. The reasoning for this was discussed on [Zulip][1] Changes: - Make `rustc-hash` optional but default to including it - Rename all occurrences of `FxHashMap` to `HashMap`. - Feature gate the import and rename the imported `FxHashMap` to `HashMap` - Introduce a type alias `FxHashMap` which resolves to the currently used `HashMap` (`rustc_hash::FxHashMap` or `std::collections::HashMap`) for use in `src/librustdoc`. [1]: https://rust-lang.zulipchat.com/#narrow/channel/266220-t-rustdoc/topic/rustc-hash.20and.20performance.20of.20rustdoc-types |
||
|---|---|---|
| .. | ||
| Cargo.toml | ||
| lib.rs | ||
| README.md | ||
| tests.rs | ||
Rustdoc JSON Types
This crate exposes the Rustdoc JSON API as a set of types with serde implementations. These types are part of the public interface of the rustdoc JSON output, and making them their own crate allows them to be versioned and distributed without having to depend on any rustc/rustdoc internals. This way, consumers can rely on this crate for both documentation of the output, and as a way to read the output easily, and its versioning is intended to follow semver guarantees about the version of the format. JSON format X will always be compatible with rustdoc-json-types version N.
Currently, this crate is only used by rustdoc itself. Upon the stabilization of rustdoc-json, it may be distributed separately for consumers of the API.