Account for gaps in def path table during decoding#79810
Account for gaps in def path table during decoding#79810bors merged 1 commit intorust-lang:masterfrom
Conversation
|
r? @lcnr (rust-highfive has picked a reviewer for you, use r? to override) |
|
This resolves the crash in issue #79783. However, I haven't been able to come up with a minimal reproduction yet, so I'm leaving that issue open for now. |
When encoding a proc-macro crate, there may be gaps in the table (since we only encode the crate root and proc-macro items). Account for this by checking if the entry is present, rather than using `unwrap()`
162abb1 to
a332e2b
Compare
|
@bors r=lcnr |
|
📌 Commit a332e2b has been approved by |
|
@bors p=1 Resolves a rustc crash on nightly. |
Rollup of 12 pull requests Successful merges: - rust-lang#79732 (minor stylistic clippy cleanups) - rust-lang#79750 (Fix trimming of lint docs) - rust-lang#79777 (Remove `first_merge` from liveness debug logs) - rust-lang#79795 (Privatize some of libcore unicode_internals) - rust-lang#79803 (Update xsv to prevent random CI failures) - rust-lang#79810 (Account for gaps in def path table during decoding) - rust-lang#79818 (Fixes to Rust coverage) - rust-lang#79824 (Strip prefix instead of replacing it with empty string) - rust-lang#79826 (Simplify visit_{foreign,trait}_item) - rust-lang#79844 (Move RWUTable to a separate module) - rust-lang#79861 (Update LLVM submodule) - rust-lang#79862 (Remove tab-lock and replace it with ctrl+up/down arrows to switch between search result tabs) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
| @@ -1561,9 +1563,12 @@ impl<'a, 'tcx> CrateMetadataRef<'a> { | |||
| let mut map = FxHashMap::with_capacity_and_hasher(end_id as usize, Default::default()); | |||
| for i in 0..end_id { | |||
There was a problem hiding this comment.
Late to the party... but if there are gaps, rather than stopping at end_id, do we need to keep iterating until we've processed self.root.tables.def_path_hashes.size() elements?
(Or maybe something more efficient. I'm not familiar with how these tables work.)
There was a problem hiding this comment.
The size() method on Lazy<Table> has a somewhat misleading name - it returns the maximum possible value. So, iterating up to end_id guarnatees that we visit all present entries.
When encoding a proc-macro crate, there may be gaps in the table (since
we only encode the crate root and proc-macro items). Account for this by
checking if the entry is present, rather than using
unwrap()