2019-12-24 04:30:02 +00:00
|
|
|
use crate::mir::mono::Linkage;
|
2020-10-08 22:23:27 +00:00
|
|
|
use rustc_attr::{InlineAttr, InstructionSetAttr, OptimizeAttr};
|
2019-12-24 04:30:02 +00:00
|
|
|
use rustc_span::symbol::Symbol;
|
2021-02-07 21:47:03 +00:00
|
|
|
use rustc_target::spec::SanitizerSet;
|
2019-12-24 04:30:02 +00:00
|
|
|
|
2021-01-03 14:19:16 +00:00
|
|
|
#[derive(Clone, TyEncodable, TyDecodable, HashStable, Debug)]
|
2019-12-24 04:30:02 +00:00
|
|
|
pub struct CodegenFnAttrs {
|
|
|
|
pub flags: CodegenFnAttrFlags,
|
|
|
|
/// Parsed representation of the `#[inline]` attribute
|
|
|
|
pub inline: InlineAttr,
|
|
|
|
/// Parsed representation of the `#[optimize]` attribute
|
|
|
|
pub optimize: OptimizeAttr,
|
|
|
|
/// The `#[export_name = "..."]` attribute, indicating a custom symbol a
|
|
|
|
/// function should be exported under
|
|
|
|
pub export_name: Option<Symbol>,
|
|
|
|
/// The `#[link_name = "..."]` attribute, indicating a custom symbol an
|
|
|
|
/// imported function should be imported as. Note that `export_name`
|
|
|
|
/// probably isn't set when this is set, this is for foreign items while
|
|
|
|
/// `#[export_name]` is for Rust-defined functions.
|
|
|
|
pub link_name: Option<Symbol>,
|
|
|
|
/// The `#[link_ordinal = "..."]` attribute, indicating an ordinal an
|
|
|
|
/// imported function has in the dynamic library. Note that this must not
|
|
|
|
/// be set when `link_name` is set. This is for foreign items with the
|
|
|
|
/// "raw-dylib" kind.
|
2021-09-11 00:34:09 +00:00
|
|
|
pub link_ordinal: Option<u16>,
|
2019-12-24 04:30:02 +00:00
|
|
|
/// The `#[target_feature(enable = "...")]` attribute and the enabled
|
|
|
|
/// features (only enabled features are supported right now).
|
|
|
|
pub target_features: Vec<Symbol>,
|
Move linkage type check to HIR analysis and fix semantics issues.
This ensures that the error is printed even for unused variables,
as well as unifying the handling between the LLVM and GCC backends.
This also fixes unusual behavior around exported Rust-defined variables
with linkage attributes. With the previous behavior, it appears to be
impossible to define such a variable such that it can actually be imported
and used by another crate. This is because on the importing side, the
variable is required to be a pointer, but on the exporting side, the
type checker rejects static variables of pointer type because they do
not implement `Sync`. Even if it were possible to import such a type, it
appears that code generation on the importing side would add an unexpected
additional level of pointer indirection, which would break type safety.
This highlighted that the semantics of linkage on Rust-defined variables
is different to linkage on foreign items. As such, we now model the
difference with two different codegen attributes: linkage for Rust-defined
variables, and import_linkage for foreign items.
This change gives semantics to the test
src/test/ui/linkage-attr/auxiliary/def_illtyped_external.rs which was
previously expected to fail to compile. Therefore, convert it into a
test that is expected to successfully compile.
The update to the GCC backend is speculative and untested.
2022-11-24 02:13:30 +00:00
|
|
|
/// The `#[linkage = "..."]` attribute on Rust-defined items and the value we found.
|
2019-12-24 04:30:02 +00:00
|
|
|
pub linkage: Option<Linkage>,
|
Move linkage type check to HIR analysis and fix semantics issues.
This ensures that the error is printed even for unused variables,
as well as unifying the handling between the LLVM and GCC backends.
This also fixes unusual behavior around exported Rust-defined variables
with linkage attributes. With the previous behavior, it appears to be
impossible to define such a variable such that it can actually be imported
and used by another crate. This is because on the importing side, the
variable is required to be a pointer, but on the exporting side, the
type checker rejects static variables of pointer type because they do
not implement `Sync`. Even if it were possible to import such a type, it
appears that code generation on the importing side would add an unexpected
additional level of pointer indirection, which would break type safety.
This highlighted that the semantics of linkage on Rust-defined variables
is different to linkage on foreign items. As such, we now model the
difference with two different codegen attributes: linkage for Rust-defined
variables, and import_linkage for foreign items.
This change gives semantics to the test
src/test/ui/linkage-attr/auxiliary/def_illtyped_external.rs which was
previously expected to fail to compile. Therefore, convert it into a
test that is expected to successfully compile.
The update to the GCC backend is speculative and untested.
2022-11-24 02:13:30 +00:00
|
|
|
/// The `#[linkage = "..."]` attribute on foreign items and the value we found.
|
|
|
|
pub import_linkage: Option<Linkage>,
|
2019-12-24 04:30:02 +00:00
|
|
|
/// The `#[link_section = "..."]` attribute, or what executable section this
|
|
|
|
/// should be placed in.
|
|
|
|
pub link_section: Option<Symbol>,
|
2020-06-14 00:00:00 +00:00
|
|
|
/// The `#[no_sanitize(...)]` attribute. Indicates sanitizers for which
|
|
|
|
/// instrumentation should be disabled inside the annotated function.
|
|
|
|
pub no_sanitize: SanitizerSet,
|
2020-10-08 22:23:27 +00:00
|
|
|
/// The `#[instruction_set(set)]` attribute. Indicates if the generated code should
|
|
|
|
/// be generated against a specific instruction set. Only usable on architectures which allow
|
|
|
|
/// switching between multiple instruction sets.
|
|
|
|
pub instruction_set: Option<InstructionSetAttr>,
|
2021-01-21 02:49:04 +00:00
|
|
|
/// The `#[repr(align(...))]` attribute. Indicates the value of which the function should be
|
|
|
|
/// aligned to.
|
|
|
|
pub alignment: Option<u32>,
|
2019-12-24 04:30:02 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
bitflags! {
|
2020-06-29 20:09:54 +00:00
|
|
|
#[derive(TyEncodable, TyDecodable, HashStable)]
|
2019-12-24 04:30:02 +00:00
|
|
|
pub struct CodegenFnAttrFlags: u32 {
|
|
|
|
/// `#[cold]`: a hint to LLVM that this function, when called, is never on
|
|
|
|
/// the hot path.
|
|
|
|
const COLD = 1 << 0;
|
|
|
|
/// `#[rustc_allocator]`: a hint to LLVM that the pointer returned from this
|
2022-03-21 19:30:54 +00:00
|
|
|
/// function is never null and the function has no side effects other than allocating.
|
2019-12-24 04:30:02 +00:00
|
|
|
const ALLOCATOR = 1 << 1;
|
2021-06-08 18:23:58 +00:00
|
|
|
/// An indicator that function will never unwind. Will become obsolete
|
|
|
|
/// once C-unwind is fully stabilized.
|
|
|
|
const NEVER_UNWIND = 1 << 3;
|
2019-12-24 04:30:02 +00:00
|
|
|
/// `#[naked]`: an indicator to LLVM that no function prologue/epilogue
|
|
|
|
/// should be generated.
|
|
|
|
const NAKED = 1 << 4;
|
|
|
|
/// `#[no_mangle]`: an indicator that the function's name should be the same
|
|
|
|
/// as its symbol.
|
|
|
|
const NO_MANGLE = 1 << 5;
|
|
|
|
/// `#[rustc_std_internal_symbol]`: an indicator that this symbol is a
|
|
|
|
/// "weird symbol" for the standard library in that it has slightly
|
|
|
|
/// different linkage, visibility, and reachability rules.
|
|
|
|
const RUSTC_STD_INTERNAL_SYMBOL = 1 << 6;
|
|
|
|
/// `#[thread_local]`: indicates a static is actually a thread local
|
|
|
|
/// piece of memory
|
|
|
|
const THREAD_LOCAL = 1 << 8;
|
|
|
|
/// `#[used]`: indicates that LLVM can't eliminate this function (but the
|
|
|
|
/// linker can!).
|
|
|
|
const USED = 1 << 9;
|
|
|
|
/// `#[ffi_returns_twice]`, indicates that an extern function can return
|
|
|
|
/// multiple times
|
|
|
|
const FFI_RETURNS_TWICE = 1 << 10;
|
|
|
|
/// `#[track_caller]`: allow access to the caller location
|
|
|
|
const TRACK_CALLER = 1 << 11;
|
2020-04-13 22:19:46 +00:00
|
|
|
/// #[ffi_pure]: applies clang's `pure` attribute to a foreign function
|
|
|
|
/// declaration.
|
2020-06-14 00:00:00 +00:00
|
|
|
const FFI_PURE = 1 << 12;
|
2020-04-13 22:19:46 +00:00
|
|
|
/// #[ffi_const]: applies clang's `const` attribute to a foreign function
|
|
|
|
/// declaration.
|
2020-06-14 00:00:00 +00:00
|
|
|
const FFI_CONST = 1 << 13;
|
2020-09-28 20:10:38 +00:00
|
|
|
/// #[cmse_nonsecure_entry]: with a TrustZone-M extension, declare a
|
|
|
|
/// function as an entry function from Non-Secure code.
|
|
|
|
const CMSE_NONSECURE_ENTRY = 1 << 14;
|
2021-04-25 20:34:03 +00:00
|
|
|
/// `#[no_coverage]`: indicates that the function should be ignored by
|
|
|
|
/// the MIR `InstrumentCoverage` pass and not added to the coverage map
|
|
|
|
/// during codegen.
|
|
|
|
const NO_COVERAGE = 1 << 15;
|
2023-02-16 16:58:08 +00:00
|
|
|
/// `#[used(linker)]`:
|
|
|
|
/// indicates that neither LLVM nor the linker will eliminate this function.
|
2021-11-22 12:14:54 +00:00
|
|
|
const USED_LINKER = 1 << 16;
|
2022-03-21 19:30:54 +00:00
|
|
|
/// `#[rustc_deallocator]`: a hint to LLVM that the function only deallocates memory.
|
|
|
|
const DEALLOCATOR = 1 << 17;
|
|
|
|
/// `#[rustc_reallocator]`: a hint to LLVM that the function only reallocates memory.
|
|
|
|
const REALLOCATOR = 1 << 18;
|
|
|
|
/// `#[rustc_allocator_zeroed]`: a hint to LLVM that the function only allocates zeroed memory.
|
|
|
|
const ALLOCATOR_ZEROED = 1 << 19;
|
2019-12-24 04:30:02 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl CodegenFnAttrs {
|
2022-05-04 09:18:37 +00:00
|
|
|
pub const EMPTY: &'static Self = &Self::new();
|
|
|
|
|
|
|
|
pub const fn new() -> CodegenFnAttrs {
|
2019-12-24 04:30:02 +00:00
|
|
|
CodegenFnAttrs {
|
|
|
|
flags: CodegenFnAttrFlags::empty(),
|
|
|
|
inline: InlineAttr::None,
|
|
|
|
optimize: OptimizeAttr::None,
|
|
|
|
export_name: None,
|
|
|
|
link_name: None,
|
|
|
|
link_ordinal: None,
|
|
|
|
target_features: vec![],
|
|
|
|
linkage: None,
|
Move linkage type check to HIR analysis and fix semantics issues.
This ensures that the error is printed even for unused variables,
as well as unifying the handling between the LLVM and GCC backends.
This also fixes unusual behavior around exported Rust-defined variables
with linkage attributes. With the previous behavior, it appears to be
impossible to define such a variable such that it can actually be imported
and used by another crate. This is because on the importing side, the
variable is required to be a pointer, but on the exporting side, the
type checker rejects static variables of pointer type because they do
not implement `Sync`. Even if it were possible to import such a type, it
appears that code generation on the importing side would add an unexpected
additional level of pointer indirection, which would break type safety.
This highlighted that the semantics of linkage on Rust-defined variables
is different to linkage on foreign items. As such, we now model the
difference with two different codegen attributes: linkage for Rust-defined
variables, and import_linkage for foreign items.
This change gives semantics to the test
src/test/ui/linkage-attr/auxiliary/def_illtyped_external.rs which was
previously expected to fail to compile. Therefore, convert it into a
test that is expected to successfully compile.
The update to the GCC backend is speculative and untested.
2022-11-24 02:13:30 +00:00
|
|
|
import_linkage: None,
|
2019-12-24 04:30:02 +00:00
|
|
|
link_section: None,
|
2020-06-14 00:00:00 +00:00
|
|
|
no_sanitize: SanitizerSet::empty(),
|
2020-10-08 22:23:27 +00:00
|
|
|
instruction_set: None,
|
2021-01-21 02:49:04 +00:00
|
|
|
alignment: None,
|
2019-12-24 04:30:02 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Returns `true` if `#[inline]` or `#[inline(always)]` is present.
|
|
|
|
pub fn requests_inline(&self) -> bool {
|
|
|
|
match self.inline {
|
|
|
|
InlineAttr::Hint | InlineAttr::Always => true,
|
|
|
|
InlineAttr::None | InlineAttr::Never => false,
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Returns `true` if it looks like this symbol needs to be exported, for example:
|
|
|
|
///
|
|
|
|
/// * `#[no_mangle]` is present
|
|
|
|
/// * `#[export_name(...)]` is present
|
|
|
|
/// * `#[linkage]` is present
|
|
|
|
pub fn contains_extern_indicator(&self) -> bool {
|
|
|
|
self.flags.contains(CodegenFnAttrFlags::NO_MANGLE)
|
|
|
|
|| self.export_name.is_some()
|
|
|
|
|| match self.linkage {
|
|
|
|
// These are private, so make sure we don't try to consider
|
|
|
|
// them external.
|
2020-04-17 00:38:52 +00:00
|
|
|
None | Some(Linkage::Internal | Linkage::Private) => false,
|
2019-12-24 04:30:02 +00:00
|
|
|
Some(_) => true,
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|