rustc_symbol_mangling/
lib.rs

1//! The Rust Linkage Model and Symbol Names
2//! =======================================
3//!
4//! The semantic model of Rust linkage is, broadly, that "there's no global
5//! namespace" between crates. Our aim is to preserve the illusion of this
6//! model despite the fact that it's not *quite* possible to implement on
7//! modern linkers. We initially didn't use system linkers at all, but have
8//! been convinced of their utility.
9//!
10//! There are a few issues to handle:
11//!
12//!  - Linkers operate on a flat namespace, so we have to flatten names.
13//!    We do this using the C++ namespace-mangling technique. Foo::bar
14//!    symbols and such.
15//!
16//!  - Symbols for distinct items with the same *name* need to get different
17//!    linkage-names. Examples of this are monomorphizations of functions or
18//!    items within anonymous scopes that end up having the same path.
19//!
20//!  - Symbols in different crates but with same names "within" the crate need
21//!    to get different linkage-names.
22//!
23//!  - Symbol names should be deterministic: Two consecutive runs of the
24//!    compiler over the same code base should produce the same symbol names for
25//!    the same items.
26//!
27//!  - Symbol names should not depend on any global properties of the code base,
28//!    so that small modifications to the code base do not result in all symbols
29//!    changing. In previous versions of the compiler, symbol names incorporated
30//!    the SVH (Stable Version Hash) of the crate. This scheme turned out to be
31//!    infeasible when used in conjunction with incremental compilation because
32//!    small code changes would invalidate all symbols generated previously.
33//!
34//!  - Even symbols from different versions of the same crate should be able to
35//!    live next to each other without conflict.
36//!
37//! In order to fulfill the above requirements the following scheme is used by
38//! the compiler:
39//!
40//! The main tool for avoiding naming conflicts is the incorporation of a 64-bit
41//! hash value into every exported symbol name. Anything that makes a difference
42//! to the symbol being named, but does not show up in the regular path needs to
43//! be fed into this hash:
44//!
45//! - Different monomorphizations of the same item have the same path but differ
46//!   in their concrete type parameters, so these parameters are part of the
47//!   data being digested for the symbol hash.
48//!
49//! - Rust allows items to be defined in anonymous scopes, such as in
50//!   `fn foo() { { fn bar() {} } { fn bar() {} } }`. Both `bar` functions have
51//!   the path `foo::bar`, since the anonymous scopes do not contribute to the
52//!   path of an item. The compiler already handles this case via so-called
53//!   disambiguating `DefPaths` which use indices to distinguish items with the
54//!   same name. The DefPaths of the functions above are thus `foo[0]::bar[0]`
55//!   and `foo[0]::bar[1]`. In order to incorporate this disambiguation
56//!   information into the symbol name too, these indices are fed into the
57//!   symbol hash, so that the above two symbols would end up with different
58//!   hash values.
59//!
60//! The two measures described above suffice to avoid intra-crate conflicts. In
61//! order to also avoid inter-crate conflicts two more measures are taken:
62//!
63//! - The name of the crate containing the symbol is prepended to the symbol
64//!   name, i.e., symbols are "crate qualified". For example, a function `foo` in
65//!   module `bar` in crate `baz` would get a symbol name like
66//!   `baz::bar::foo::{hash}` instead of just `bar::foo::{hash}`. This avoids
67//!   simple conflicts between functions from different crates.
68//!
69//! - In order to be able to also use symbols from two versions of the same
70//!   crate (which naturally also have the same name), a stronger measure is
71//!   required: The compiler accepts an arbitrary "disambiguator" value via the
72//!   `-C metadata` command-line argument. This disambiguator is then fed into
73//!   the symbol hash of every exported item. Consequently, the symbols in two
74//!   identical crates but with different disambiguators are not in conflict
75//!   with each other. This facility is mainly intended to be used by build
76//!   tools like Cargo.
77//!
78//! A note on symbol name stability
79//! -------------------------------
80//! Previous versions of the compiler resorted to feeding NodeIds into the
81//! symbol hash in order to disambiguate between items with the same path. The
82//! current version of the name generation algorithm takes great care not to do
83//! that, since NodeIds are notoriously unstable: A small change to the
84//! code base will offset all NodeIds after the change and thus, much as using
85//! the SVH in the hash, invalidate an unbounded number of symbol names. This
86//! makes re-using previously compiled code for incremental compilation
87//! virtually impossible. Thus, symbol hash generation exclusively relies on
88//! DefPaths which are much more robust in the face of changes to the code base.
89
90// tidy-alphabetical-start
91#![allow(internal_features)]
92#![cfg_attr(bootstrap, feature(let_chains))]
93#![doc(html_root_url = "https://doc.rust-lang.org/nightly/nightly-rustc/")]
94#![doc(rust_logo)]
95#![feature(assert_matches)]
96#![feature(rustdoc_internals)]
97// tidy-alphabetical-end
98
99use rustc_hir::def::DefKind;
100use rustc_hir::def_id::{CrateNum, LOCAL_CRATE};
101use rustc_middle::middle::codegen_fn_attrs::{CodegenFnAttrFlags, CodegenFnAttrs};
102use rustc_middle::mir::mono::{InstantiationMode, MonoItem};
103use rustc_middle::query::Providers;
104use rustc_middle::ty::{self, Instance, TyCtxt};
105use rustc_session::config::SymbolManglingVersion;
106use tracing::debug;
107
108mod export;
109mod hashed;
110mod legacy;
111mod v0;
112
113pub mod errors;
114pub mod test;
115
116pub use v0::mangle_internal_symbol;
117
118/// This function computes the symbol name for the given `instance` and the
119/// given instantiating crate. That is, if you know that instance X is
120/// instantiated in crate Y, this is the symbol name this instance would have.
121pub fn symbol_name_for_instance_in_crate<'tcx>(
122    tcx: TyCtxt<'tcx>,
123    instance: Instance<'tcx>,
124    instantiating_crate: CrateNum,
125) -> String {
126    compute_symbol_name(tcx, instance, || instantiating_crate)
127}
128
129pub fn provide(providers: &mut Providers) {
130    *providers = Providers { symbol_name: symbol_name_provider, ..*providers };
131}
132
133// The `symbol_name` query provides the symbol name for calling a given
134// instance from the local crate. In particular, it will also look up the
135// correct symbol name of instances from upstream crates.
136fn symbol_name_provider<'tcx>(tcx: TyCtxt<'tcx>, instance: Instance<'tcx>) -> ty::SymbolName<'tcx> {
137    let symbol_name = compute_symbol_name(tcx, instance, || {
138        // This closure determines the instantiating crate for instances that
139        // need an instantiating-crate-suffix for their symbol name, in order
140        // to differentiate between local copies.
141        if is_generic(instance) {
142            // For generics we might find re-usable upstream instances. If there
143            // is one, we rely on the symbol being instantiated locally.
144            instance.upstream_monomorphization(tcx).unwrap_or(LOCAL_CRATE)
145        } else {
146            // For non-generic things that need to avoid naming conflicts, we
147            // always instantiate a copy in the local crate.
148            LOCAL_CRATE
149        }
150    });
151
152    ty::SymbolName::new(tcx, &symbol_name)
153}
154
155pub fn typeid_for_trait_ref<'tcx>(
156    tcx: TyCtxt<'tcx>,
157    trait_ref: ty::ExistentialTraitRef<'tcx>,
158) -> String {
159    v0::mangle_typeid_for_trait_ref(tcx, trait_ref)
160}
161
162/// Computes the symbol name for the given instance. This function will call
163/// `compute_instantiating_crate` if it needs to factor the instantiating crate
164/// into the symbol name.
165fn compute_symbol_name<'tcx>(
166    tcx: TyCtxt<'tcx>,
167    instance: Instance<'tcx>,
168    compute_instantiating_crate: impl FnOnce() -> CrateNum,
169) -> String {
170    let def_id = instance.def_id();
171    let args = instance.args;
172
173    debug!("symbol_name(def_id={:?}, args={:?})", def_id, args);
174
175    if let Some(def_id) = def_id.as_local() {
176        if tcx.proc_macro_decls_static(()) == Some(def_id) {
177            let stable_crate_id = tcx.stable_crate_id(LOCAL_CRATE);
178            return tcx.sess.generate_proc_macro_decls_symbol(stable_crate_id);
179        }
180    }
181
182    // FIXME(eddyb) Precompute a custom symbol name based on attributes.
183    let attrs = if tcx.def_kind(def_id).has_codegen_attrs() {
184        tcx.codegen_fn_attrs(def_id)
185    } else {
186        CodegenFnAttrs::EMPTY
187    };
188
189    if attrs.flags.contains(CodegenFnAttrFlags::RUSTC_STD_INTERNAL_SYMBOL) {
190        // Items marked as #[rustc_std_internal_symbol] need to have a fixed
191        // symbol name because it is used to import items from another crate
192        // without a direct dependency. As such it is not possible to look up
193        // the mangled name for the `Instance` from the crate metadata of the
194        // defining crate.
195        // Weak lang items automatically get #[rustc_std_internal_symbol]
196        // applied by the code computing the CodegenFnAttrs.
197        // We are mangling all #[rustc_std_internal_symbol] items that don't
198        // also have #[no_mangle] as a combination of the rustc version and the
199        // unmangled linkage name. This is to ensure that if we link against a
200        // staticlib compiled by a different rustc version, we don't get symbol
201        // conflicts or even UB due to a different implementation/ABI. Rust
202        // staticlibs currently export all symbols, including those that are
203        // hidden in cdylibs.
204        // We are using the v0 symbol mangling scheme here as we need to be
205        // consistent across all crates and in some contexts the legacy symbol
206        // mangling scheme can't be used. For example both the GCC backend and
207        // Rust-for-Linux don't support some of the characters used by the
208        // legacy symbol mangling scheme.
209        let name = if tcx.is_foreign_item(def_id) {
210            if let Some(name) = attrs.link_name { name } else { tcx.item_name(def_id) }
211        } else {
212            if let Some(name) = attrs.export_name { name } else { tcx.item_name(def_id) }
213        };
214
215        if attrs.flags.contains(CodegenFnAttrFlags::NO_MANGLE) {
216            return name.to_string();
217        } else {
218            return v0::mangle_internal_symbol(tcx, name.as_str());
219        }
220    }
221
222    // Foreign items by default use no mangling for their symbol name. There's a
223    // few exceptions to this rule though:
224    //
225    // * This can be overridden with the `#[link_name]` attribute
226    //
227    // * On the wasm32 targets there is a bug (or feature) in LLD [1] where the
228    //   same-named symbol when imported from different wasm modules will get
229    //   hooked up incorrectly. As a result foreign symbols, on the wasm target,
230    //   with a wasm import module, get mangled. Additionally our codegen will
231    //   deduplicate symbols based purely on the symbol name, but for wasm this
232    //   isn't quite right because the same-named symbol on wasm can come from
233    //   different modules. For these reasons if `#[link(wasm_import_module)]`
234    //   is present we mangle everything on wasm because the demangled form will
235    //   show up in the `wasm-import-name` custom attribute in LLVM IR.
236    //
237    // * `#[rustc_std_internal_symbol]` mangles the symbol name in a special way
238    //   both for exports and imports through foreign items. This is handled above.
239    // [1]: https://bugs.llvm.org/show_bug.cgi?id=44316
240    if tcx.is_foreign_item(def_id)
241        && (!tcx.sess.target.is_like_wasm
242            || !tcx.wasm_import_module_map(def_id.krate).contains_key(&def_id))
243    {
244        if let Some(name) = attrs.link_name {
245            return name.to_string();
246        }
247        return tcx.item_name(def_id).to_string();
248    }
249
250    if let Some(name) = attrs.export_name {
251        // Use provided name
252        return name.to_string();
253    }
254
255    if attrs.flags.contains(CodegenFnAttrFlags::NO_MANGLE) {
256        // Don't mangle
257        return tcx.item_name(def_id).to_string();
258    }
259
260    // If we're dealing with an instance of a function that's inlined from
261    // another crate but we're marking it as globally shared to our
262    // compilation (aka we're not making an internal copy in each of our
263    // codegen units) then this symbol may become an exported (but hidden
264    // visibility) symbol. This means that multiple crates may do the same
265    // and we want to be sure to avoid any symbol conflicts here.
266    let is_globally_shared_function = matches!(
267        tcx.def_kind(instance.def_id()),
268        DefKind::Fn
269            | DefKind::AssocFn
270            | DefKind::Closure
271            | DefKind::SyntheticCoroutineBody
272            | DefKind::Ctor(..)
273    ) && matches!(
274        MonoItem::Fn(instance).instantiation_mode(tcx),
275        InstantiationMode::GloballyShared { may_conflict: true }
276    );
277
278    // If this is an instance of a generic function, we also hash in
279    // the ID of the instantiating crate. This avoids symbol conflicts
280    // in case the same instances is emitted in two crates of the same
281    // project.
282    let avoid_cross_crate_conflicts = is_generic(instance) || is_globally_shared_function;
283
284    let instantiating_crate = avoid_cross_crate_conflicts.then(compute_instantiating_crate);
285
286    // Pick the crate responsible for the symbol mangling version, which has to:
287    // 1. be stable for each instance, whether it's being defined or imported
288    // 2. obey each crate's own `-C symbol-mangling-version`, as much as possible
289    // We solve these as follows:
290    // 1. because symbol names depend on both `def_id` and `instantiating_crate`,
291    // both their `CrateNum`s are stable for any given instance, so we can pick
292    // either and have a stable choice of symbol mangling version
293    // 2. we favor `instantiating_crate` where possible (i.e. when `Some`)
294    let mangling_version_crate = instantiating_crate.unwrap_or(def_id.krate);
295    let mangling_version = if mangling_version_crate == LOCAL_CRATE {
296        tcx.sess.opts.get_symbol_mangling_version()
297    } else {
298        tcx.symbol_mangling_version(mangling_version_crate)
299    };
300
301    let symbol = match tcx.is_exportable(def_id) {
302        true => format!(
303            "{}.{}",
304            v0::mangle(tcx, instance, instantiating_crate, true),
305            export::compute_hash_of_export_fn(tcx, instance)
306        ),
307        false => match mangling_version {
308            SymbolManglingVersion::Legacy => legacy::mangle(tcx, instance, instantiating_crate),
309            SymbolManglingVersion::V0 => v0::mangle(tcx, instance, instantiating_crate, false),
310            SymbolManglingVersion::Hashed => {
311                hashed::mangle(tcx, instance, instantiating_crate, || {
312                    v0::mangle(tcx, instance, instantiating_crate, false)
313                })
314            }
315        },
316    };
317
318    debug_assert!(
319        rustc_demangle::try_demangle(&symbol).is_ok(),
320        "compute_symbol_name: `{symbol}` cannot be demangled"
321    );
322
323    symbol
324}
325
326fn is_generic<'tcx>(instance: Instance<'tcx>) -> bool {
327    instance.args.non_erasable_generics().next().is_some()
328}