hir: Do not introduce dummy type names for extern blocks in def paths#92032
hir: Do not introduce dummy type names for extern blocks in def paths#92032bors merged 1 commit intorust-lang:masterfrom
extern blocks in def paths#92032Conversation
|
r? @oli-obk (rust-highfive has picked a reviewer for you, use r? to override) |
8a46c87 to
66e232f
Compare
|
Is this testable on master? |
|
This should be a pure refactoring (maybe with exception of some debug logging where |
|
@bors r+ rollup |
|
📌 Commit 66e232fcb27478ce9f0f404dfc24b09a8426cef0 has been approved by |
There was a problem hiding this comment.
I forgot to remove the FIXME a couple of lines below, will fix tomorrow.
|
@bors r- |
src/librustdoc/clean/inline.rs
Outdated
There was a problem hiding this comment.
cc #91948: How does this interact with that PR, specifically #91948 (comment)?
There was a problem hiding this comment.
When both PRs are merged this will turn into just elem.data.get_opt_name().
66e232f to
fbe4f5e
Compare
Use a separate nameless `DefPathData` variant instead
fbe4f5e to
0d61852
Compare
|
Updated with #92032 (comment) addressed. |
|
📌 Commit 0d61852 has been approved by |
…askrgr Rollup of 7 pull requests Successful merges: - rust-lang#91858 (pass -Wl,-z,origin to set DF_ORIGIN when using rpath) - rust-lang#91923 (Remove `in_band_lifetimes` from `rustc_query_impl`) - rust-lang#91925 (Remove `in_band_lifetimes` from `rustc_privacy`) - rust-lang#91977 (Clean up search code and unify function returned values) - rust-lang#92018 (Fix typo in "new region bound" suggestion) - rust-lang#92022 (Eliminate duplicate codes of expected_found_bool) - rust-lang#92032 (hir: Do not introduce dummy type names for `extern` blocks in def paths) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
| let ns = match disambiguated_data.data { | ||
| // FIXME: It shouldn't be necessary to add anything for extern block segments, | ||
| // but we add 't' for backward compatibility. | ||
| DefPathData::ForeignMod => 't', |
There was a problem hiding this comment.
Is this code actually reachable? What will the demangled symbol look like?
There was a problem hiding this comment.
Yes, it's reachable.
Functions and statics in foreign blocks are not mangled, but foreign types are mangled when they are used in any non-foreign symbols.
Something like
extern { type Type; }
fn foo(_arg: &Type) {}mangling_v0: Skip extern blocks during mangling There's no need to include the dummy `Nt` into the symbol name, items in extern blocks belong to their parent modules for all purposes except for inheriting the ABI and attributes. Follow up to rust-lang#92032 (There's also a drive-by fix to the `rust-demangler` tool's tests, which don't run on CI, I initially attempted using them for testing this PR.)
mangling_v0: Skip extern blocks during mangling There's no need to include the dummy `Nt` into the symbol name, items in extern blocks belong to their parent modules for all purposes except for inheriting the ABI and attributes. Follow up to rust-lang#92032 (There's also a drive-by fix to the `rust-demangler` tool's tests, which don't run on CI, I initially attempted using them for testing this PR.)
mangling_v0: Skip extern blocks during mangling There's no need to include the dummy `Nt` into the symbol name, items in extern blocks belong to their parent modules for all purposes except for inheriting the ABI and attributes. Follow up to rust-lang#92032 (There's also a drive-by fix to the `rust-demangler` tool's tests, which don't run on CI, I initially attempted using them for testing this PR.)
mangling_v0: Skip extern blocks during mangling There's no need to include the dummy `Nt` into the symbol name, items in extern blocks belong to their parent modules for all purposes except for inheriting the ABI and attributes. Follow up to rust-lang#92032 (There's also a drive-by fix to the `rust-demangler` tool's tests, which don't run on CI, I initially attempted using them for testing this PR.)
Use a separate nameless
DefPathDatavariant instead.Extracted from #91795.