]> git.proxmox.com Git - rustc.git/blame - compiler/rustc_symbol_mangling/src/lib.rs
New upstream version 1.69.0+dfsg1
[rustc.git] / compiler / rustc_symbol_mangling / src / lib.rs
CommitLineData
54a0048b
SL
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
0731742a 64//! name, i.e., symbols are "crate qualified". For example, a function `foo` in
54a0048b
SL
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
a1dfa0c6 72//! `-C metadata` command-line argument. This disambiguator is then fed into
54a0048b
SL
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
1b1a35ee 90#![doc(html_root_url = "https://doc.rust-lang.org/nightly/nightly-rustc/")]
ba9703b0 91#![feature(never_type)]
ba9703b0 92#![recursion_limit = "256"]
5e7ed085 93#![allow(rustc::potential_query_instability)]
f2b60f7d
FG
94#![deny(rustc::untranslatable_diagnostic)]
95#![deny(rustc::diagnostic_outside_of_impl)]
ba9703b0
XL
96
97#[macro_use]
98extern crate rustc_middle;
99
f2b60f7d
FG
100#[macro_use]
101extern crate tracing;
102
9ffffee4 103use rustc_errors::{DiagnosticMessage, SubdiagnosticMessage};
04454e1e 104use rustc_hir::def::DefKind;
dfeec247 105use rustc_hir::def_id::{CrateNum, LOCAL_CRATE};
9ffffee4 106use rustc_macros::fluent_messages;
ba9703b0 107use rustc_middle::middle::codegen_fn_attrs::CodegenFnAttrFlags;
04454e1e 108use rustc_middle::middle::codegen_fn_attrs::CodegenFnAttrs;
ba9703b0
XL
109use rustc_middle::mir::mono::{InstantiationMode, MonoItem};
110use rustc_middle::ty::query::Providers;
111use rustc_middle::ty::subst::SubstsRef;
064997fb 112use rustc_middle::ty::{self, Instance, TyCtxt};
ba9703b0 113use rustc_session::config::SymbolManglingVersion;
54a0048b 114
dc9dc135
XL
115mod legacy;
116mod v0;
54a0048b 117
f2b60f7d 118pub mod errors;
ba9703b0 119pub mod test;
064997fb 120pub mod typeid;
ba9703b0 121
9ffffee4
FG
122fluent_messages! { "../locales/en-US.ftl" }
123
dfeec247
XL
124/// This function computes the symbol name for the given `instance` and the
125/// given instantiating crate. That is, if you know that instance X is
126/// instantiated in crate Y, this is the symbol name this instance would have.
a2a8927a 127pub fn symbol_name_for_instance_in_crate<'tcx>(
dfeec247
XL
128 tcx: TyCtxt<'tcx>,
129 instance: Instance<'tcx>,
130 instantiating_crate: CrateNum,
131) -> String {
132 compute_symbol_name(tcx, instance, || instantiating_crate)
133}
134
f035d41b 135pub fn provide(providers: &mut Providers) {
dfeec247
XL
136 *providers = Providers { symbol_name: symbol_name_provider, ..*providers };
137}
ea8adc8c 138
dfeec247
XL
139// The `symbol_name` query provides the symbol name for calling a given
140// instance from the local crate. In particular, it will also look up the
141// correct symbol name of instances from upstream crates.
a2a8927a 142fn symbol_name_provider<'tcx>(tcx: TyCtxt<'tcx>, instance: Instance<'tcx>) -> ty::SymbolName<'tcx> {
dfeec247
XL
143 let symbol_name = compute_symbol_name(tcx, instance, || {
144 // This closure determines the instantiating crate for instances that
145 // need an instantiating-crate-suffix for their symbol name, in order
146 // to differentiate between local copies.
147 if is_generic(instance.substs) {
148 // For generics we might find re-usable upstream instances. If there
149 // is one, we rely on the symbol being instantiated locally.
150 instance.upstream_monomorphization(tcx).unwrap_or(LOCAL_CRATE)
151 } else {
152 // For non-generic things that need to avoid naming conflicts, we
153 // always instantiate a copy in the local crate.
154 LOCAL_CRATE
155 }
156 });
157
3dfed10e 158 ty::SymbolName::new(tcx, &symbol_name)
7cac9316
XL
159}
160
923072b8
FG
161pub fn typeid_for_trait_ref<'tcx>(
162 tcx: TyCtxt<'tcx>,
163 trait_ref: ty::PolyExistentialTraitRef<'tcx>,
164) -> String {
165 v0::mangle_typeid_for_trait_ref(tcx, trait_ref)
166}
167
dfeec247
XL
168/// Computes the symbol name for the given instance. This function will call
169/// `compute_instantiating_crate` if it needs to factor the instantiating crate
170/// into the symbol name.
a2a8927a 171fn compute_symbol_name<'tcx>(
dfeec247
XL
172 tcx: TyCtxt<'tcx>,
173 instance: Instance<'tcx>,
174 compute_instantiating_crate: impl FnOnce() -> CrateNum,
175) -> String {
cc61c64b
XL
176 let def_id = instance.def_id();
177 let substs = instance.substs;
3157f602 178
94b46f34 179 debug!("symbol_name(def_id={:?}, substs={:?})", def_id, substs);
54a0048b 180
04454e1e 181 if let Some(def_id) = def_id.as_local() {
17df50a5 182 if tcx.proc_macro_decls_static(()) == Some(def_id) {
136023e0
XL
183 let stable_crate_id = tcx.sess.local_stable_crate_id();
184 return tcx.sess.generate_proc_macro_decls_symbol(stable_crate_id);
3157f602 185 }
04454e1e
FG
186 }
187
188 // FIXME(eddyb) Precompute a custom symbol name based on attributes.
189 let attrs = if tcx.def_kind(def_id).has_codegen_attrs() {
190 tcx.codegen_fn_attrs(def_id)
cc61c64b 191 } else {
04454e1e 192 CodegenFnAttrs::EMPTY
cc61c64b 193 };
54a0048b 194
dfeec247
XL
195 // Foreign items by default use no mangling for their symbol name. There's a
196 // few exceptions to this rule though:
197 //
198 // * This can be overridden with the `#[link_name]` attribute
199 //
200 // * On the wasm32 targets there is a bug (or feature) in LLD [1] where the
201 // same-named symbol when imported from different wasm modules will get
74b04a01 202 // hooked up incorrectly. As a result foreign symbols, on the wasm target,
dfeec247
XL
203 // with a wasm import module, get mangled. Additionally our codegen will
204 // deduplicate symbols based purely on the symbol name, but for wasm this
205 // isn't quite right because the same-named symbol on wasm can come from
206 // different modules. For these reasons if `#[link(wasm_import_module)]`
207 // is present we mangle everything on wasm because the demangled form will
208 // show up in the `wasm-import-name` custom attribute in LLVM IR.
209 //
210 // [1]: https://bugs.llvm.org/show_bug.cgi?id=44316
04454e1e 211 if tcx.is_foreign_item(def_id)
cdc7bbd5 212 && (!tcx.sess.target.is_like_wasm
29967ef6
XL
213 || !tcx.wasm_import_module_map(def_id.krate).contains_key(&def_id))
214 {
215 if let Some(name) = attrs.link_name {
216 return name.to_string();
3157f602 217 }
29967ef6 218 return tcx.item_name(def_id).to_string();
cc61c64b 219 }
54a0048b 220
e74abb32 221 if let Some(name) = attrs.export_name {
cc61c64b 222 // Use provided name
dfeec247 223 return name.to_string();
cc61c64b 224 }
54a0048b 225
b7449926 226 if attrs.flags.contains(CodegenFnAttrFlags::NO_MANGLE) {
cc61c64b 227 // Don't mangle
dfeec247 228 return tcx.item_name(def_id).to_string();
dc9dc135
XL
229 }
230
04454e1e
FG
231 // If we're dealing with an instance of a function that's inlined from
232 // another crate but we're marking it as globally shared to our
233 // compilation (aka we're not making an internal copy in each of our
234 // codegen units) then this symbol may become an exported (but hidden
235 // visibility) symbol. This means that multiple crates may do the same
236 // and we want to be sure to avoid any symbol conflicts here.
237 let is_globally_shared_function = matches!(
238 tcx.def_kind(instance.def_id()),
239 DefKind::Fn | DefKind::AssocFn | DefKind::Closure | DefKind::Generator | DefKind::Ctor(..)
240 ) && matches!(
241 MonoItem::Fn(instance).instantiation_mode(tcx),
242 InstantiationMode::GloballyShared { may_conflict: true }
243 );
244
245 // If this is an instance of a generic function, we also hash in
246 // the ID of the instantiating crate. This avoids symbol conflicts
247 // in case the same instances is emitted in two crates of the same
248 // project.
249 let avoid_cross_crate_conflicts = is_generic(substs) || is_globally_shared_function;
54a0048b 250
9ffffee4 251 let instantiating_crate = avoid_cross_crate_conflicts.then(compute_instantiating_crate);
9fa01778 252
dc9dc135
XL
253 // Pick the crate responsible for the symbol mangling version, which has to:
254 // 1. be stable for each instance, whether it's being defined or imported
a2a8927a 255 // 2. obey each crate's own `-C symbol-mangling-version`, as much as possible
dc9dc135
XL
256 // We solve these as follows:
257 // 1. because symbol names depend on both `def_id` and `instantiating_crate`,
258 // both their `CrateNum`s are stable for any given instance, so we can pick
259 // either and have a stable choice of symbol mangling version
260 // 2. we favor `instantiating_crate` where possible (i.e. when `Some`)
261 let mangling_version_crate = instantiating_crate.unwrap_or(def_id.krate);
262 let mangling_version = if mangling_version_crate == LOCAL_CRATE {
a2a8927a 263 tcx.sess.opts.get_symbol_mangling_version()
dc9dc135
XL
264 } else {
265 tcx.symbol_mangling_version(mangling_version_crate)
266 };
9fa01778 267
94222f64 268 let symbol = match mangling_version {
dc9dc135
XL
269 SymbolManglingVersion::Legacy => legacy::mangle(tcx, instance, instantiating_crate),
270 SymbolManglingVersion::V0 => v0::mangle(tcx, instance, instantiating_crate),
94222f64
XL
271 };
272
273 debug_assert!(
274 rustc_demangle::try_demangle(&symbol).is_ok(),
9c376795 275 "compute_symbol_name: `{symbol}` cannot be demangled"
94222f64
XL
276 );
277
278 symbol
dfeec247 279}
9fa01778 280
dfeec247
XL
281fn is_generic(substs: SubstsRef<'_>) -> bool {
282 substs.non_erasable_generics().next().is_some()
54a0048b 283}