Re-export hashbrown::hash_table from rustc_data_structures
#151890
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Collaborator
|
Some changes occurred to MIR optimizations cc @rust-lang/wg-mir-opt |
rustbot
added
A-query-system
Collaborator
This comment has been minimized.
This comment has been minimized.
Member
|
looks reasonable r? me @bors r+ rollup |
Contributor
rust-bors
bot
added
the
S-waiting-on-bors
rust-bors
bot
removed
the
S-waiting-on-review
rust-bors bot
pushed a commit
that referenced
this pull request
Jan 31, 2026
…uwer Rollup of 5 pull requests Successful merges: - #151886 (Skip unused_allocation lint when method takes &Box<Self>) - #150300 (Constify `fmt::from_fn`) - #151102 (Feature-gate `mut ref` patterns in struct pattern field shorthand) - #151866 (Reorganizing `tests/ui/issues` 10 tests [4/N] ) - #151890 (Re-export `hashbrown::hash_table` from `rustc_data_structures`)
rust-timer
added a commit
that referenced
this pull request
Feb 1, 2026
Rollup merge of #151890 - Zalathar:hash-table, r=Kivooeo Re-export `hashbrown::hash_table` from `rustc_data_structures` We don't always re-export shared dependencies, but for `hashbrown::hash_table` I think it makes sense, for a few reasons: - The lower-level `HashTable` type is already part of the public API of `rustc_data_structures` via the `ShardedHashMap` type alias, and other compiler crates currently depend on being able to access its internal hash tables. - The `Cargo.toml` entry for `hashbrown` is non-trivial, making it harder to keep in sync and harder to move between crates as needed. - [And we currently aren't using `[workspace.dependencies]` for various reasons.](#146113) - It's fine for other compiler crates to use `hash_table` specifically (with care), but they probably shouldn't be using the higher-level `hashbrown::HashMap` and `hashbrown::HashSet` types directly, because they should prefer the various map/set aliases defined by `rustc_data_structures`. Re-exporting only `hash_table` helps to discourage use of those other types. There should be no change to compiler behaviour.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We don't always re-export shared dependencies, but for
hashbrown::hash_tableI think it makes sense, for a few reasons:HashTabletype is already part of the public API ofrustc_data_structuresvia theShardedHashMaptype alias, and other compiler crates currently depend on being able to access its internal hash tables.Cargo.tomlentry forhashbrownis non-trivial, making it harder to keep in sync and harder to move between crates as needed.[workspace.dependencies]for various reasons.hash_tablespecifically (with care), but they probably shouldn't be using the higher-levelhashbrown::HashMapandhashbrown::HashSettypes directly, because they should prefer the various map/set aliases defined byrustc_data_structures. Re-exporting onlyhash_tablehelps to discourage use of those other types.There should be no change to compiler behaviour.