Make DocLinkResMap an FxIndexMap#159718
Open
jprochazk wants to merge 1 commit into
Open
Conversation
rustbot
added
A-run-make
Collaborator
|
rustbot has assigned @petrochenkov. Use Why was this reviewer chosen?The reviewer was selected based on:
|
This comment has been minimized.
This comment has been minimized.
jprochazk
force-pushed
the
doc-link-res-index-map
branch
from
July 22, 2026 13:28
6338fe7 to
66a783d
Compare
This comment has been minimized.
This comment has been minimized.
jprochazk
force-pushed
the
doc-link-res-index-map
branch
from
July 22, 2026 13:29
66a783d to
b8365e9
Compare
This comment has been minimized.
This comment has been minimized.
mejrs
reviewed
Jul 22, 2026
Contributor
|
r=me after squashing commits. |
rustbot
added
S-waiting-on-author
Collaborator
|
Reminder, once the PR becomes ready for a review, use |
also add regression test for rmeta reproducibility when unrelated `rlib` are in the search path Co-authored-by: mejrs <59372212+mejrs@users.noreply.github.com>
jprochazk
force-pushed
the
doc-link-res-index-map
branch
from
July 22, 2026 15:33
6fe4fa7 to
70b89c3
Compare
Contributor
Author
|
Squashed into one commit @rustbot ready |
rustbot
added
S-waiting-on-review
Contributor
|
Thanks! @bors r=petrochenkov |
Contributor
rust-bors
Bot
added
S-waiting-on-bors
JonathanBrouwer
added a commit
to JonathanBrouwer/rust
that referenced
this pull request
Jul 22, 2026
…r=petrochenkov Make `DocLinkResMap` an `FxIndexMap` Previously it was `FxHashMap`, changed to `UnordMap` in rust-lang#119093. The rationale then was to make the iteration order unobservable, but it turned out to be leaky. This change means the encoder outputs `doc_link_resolutions` entries in insertion order, and iteration order of the `DocLinkResMap` is now observable. I believe this doesn't affect correctness elsewhere, but I'm not very familiar with the codebase so I may be missing something * Closes rust-lang#159677 Discussed on zulip: [#t-compiler/help > rust-lang#159677: rmeta encoding is not stable](https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/.23159677.3A.20rmeta.20encoding.20is.20not.20stable/with/612134270)
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
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.
Previously it was
FxHashMap, changed toUnordMapin #119093. The rationale then was to make the iteration order unobservable, but it turned out to be leaky.This change means the encoder outputs
doc_link_resolutionsentries in insertion order, and iteration order of theDocLinkResMapis now observable. I believe this doesn't affect correctness elsewhere, but I'm not very familiar with the codebase so I may be missing something.rmetacontents depend on unrelated files in the library search path #159677Discussed on zulip: #t-compiler/help > #159677: rmeta encoding is not stable