From 75561c446afb63444e9b192563d46eccf7051c61 Mon Sep 17 00:00:00 2001 From: Anne Stijns Date: Sun, 29 Jun 2025 23:39:09 +0200 Subject: Port `#[link_ordinal]` to the new attribute parsing infrastructure. --- compiler/rustc_codegen_ssa/messages.ftl | 6 --- compiler/rustc_codegen_ssa/src/codegen_attrs.rs | 49 ++----------------------- compiler/rustc_codegen_ssa/src/errors.rs | 16 -------- 3 files changed, 4 insertions(+), 67 deletions(-) (limited to 'compiler/rustc_codegen_ssa') diff --git a/compiler/rustc_codegen_ssa/messages.ftl b/compiler/rustc_codegen_ssa/messages.ftl index 63e9005da45..c7bd6ffd1f2 100644 --- a/compiler/rustc_codegen_ssa/messages.ftl +++ b/compiler/rustc_codegen_ssa/messages.ftl @@ -80,9 +80,6 @@ codegen_ssa_ignoring_emit_path = ignoring emit path because multiple .{$extensio codegen_ssa_ignoring_output = ignoring -o because multiple .{$extension} files were produced -codegen_ssa_illegal_link_ordinal_format = illegal ordinal format in `link_ordinal` - .note = an unsuffixed integer value, e.g., `1`, is expected - codegen_ssa_incorrect_cgu_reuse_type = CGU-reuse for `{$cgu_user_name}` is `{$actual_reuse}` but should be {$at_least -> [one] {"at least "} @@ -93,9 +90,6 @@ codegen_ssa_insufficient_vs_code_product = VS Code is a different product, and i codegen_ssa_invalid_instruction_set = invalid instruction set specified -codegen_ssa_invalid_link_ordinal_nargs = incorrect number of arguments to `#[link_ordinal]` - .note = the attribute requires exactly one argument - codegen_ssa_invalid_literal_value = invalid literal value .label = value must be an integer between `0` and `255` diff --git a/compiler/rustc_codegen_ssa/src/codegen_attrs.rs b/compiler/rustc_codegen_ssa/src/codegen_attrs.rs index 85d01d4f938..dd49db26689 100644 --- a/compiler/rustc_codegen_ssa/src/codegen_attrs.rs +++ b/compiler/rustc_codegen_ssa/src/codegen_attrs.rs @@ -116,6 +116,10 @@ fn codegen_fn_attrs(tcx: TyCtxt<'_>, did: LocalDefId) -> CodegenFnAttrs { AttributeKind::Naked(_) => codegen_fn_attrs.flags |= CodegenFnAttrFlags::NAKED, AttributeKind::Align { align, .. } => codegen_fn_attrs.alignment = Some(*align), AttributeKind::LinkName { name, .. } => codegen_fn_attrs.link_name = Some(*name), + AttributeKind::LinkOrdinal { ordinal, span } => { + codegen_fn_attrs.link_ordinal = Some(*ordinal); + link_ordinal_span = Some(*span); + } AttributeKind::LinkSection { name, .. } => { codegen_fn_attrs.link_section = Some(*name) } @@ -250,12 +254,6 @@ fn codegen_fn_attrs(tcx: TyCtxt<'_>, did: LocalDefId) -> CodegenFnAttrs { } } } - sym::link_ordinal => { - link_ordinal_span = Some(attr.span()); - if let ordinal @ Some(_) = check_link_ordinal(tcx, attr) { - codegen_fn_attrs.link_ordinal = ordinal; - } - } sym::no_sanitize => { no_sanitize_span = Some(attr.span()); if let Some(list) = attr.meta_item_list() { @@ -568,45 +566,6 @@ fn inherited_align<'tcx>(tcx: TyCtxt<'tcx>, def_id: DefId) -> Option { tcx.codegen_fn_attrs(opt_trait_item(tcx, def_id)?).alignment } -fn check_link_ordinal(tcx: TyCtxt<'_>, attr: &hir::Attribute) -> Option { - use rustc_ast::{LitIntType, LitKind, MetaItemLit}; - let meta_item_list = attr.meta_item_list()?; - let [sole_meta_list] = &meta_item_list[..] else { - tcx.dcx().emit_err(errors::InvalidLinkOrdinalNargs { span: attr.span() }); - return None; - }; - if let Some(MetaItemLit { kind: LitKind::Int(ordinal, LitIntType::Unsuffixed), .. }) = - sole_meta_list.lit() - { - // According to the table at - // https://docs.microsoft.com/en-us/windows/win32/debug/pe-format#import-header, the - // ordinal must fit into 16 bits. Similarly, the Ordinal field in COFFShortExport (defined - // in llvm/include/llvm/Object/COFFImportFile.h), which we use to communicate import - // information to LLVM for `#[link(kind = "raw-dylib"_])`, is also defined to be uint16_t. - // - // FIXME: should we allow an ordinal of 0? The MSVC toolchain has inconsistent support for - // this: both LINK.EXE and LIB.EXE signal errors and abort when given a .DEF file that - // specifies a zero ordinal. However, llvm-dlltool is perfectly happy to generate an import - // library for such a .DEF file, and MSVC's LINK.EXE is also perfectly happy to consume an - // import library produced by LLVM with an ordinal of 0, and it generates an .EXE. (I - // don't know yet if the resulting EXE runs, as I haven't yet built the necessary DLL -- - // see earlier comment about LINK.EXE failing.) - if *ordinal <= u16::MAX as u128 { - Some(ordinal.get() as u16) - } else { - let msg = format!("ordinal value in `link_ordinal` is too large: `{ordinal}`"); - tcx.dcx() - .struct_span_err(attr.span(), msg) - .with_note("the value may not exceed `u16::MAX`") - .emit(); - None - } - } else { - tcx.dcx().emit_err(errors::InvalidLinkOrdinalFormat { span: attr.span() }); - None - } -} - fn check_link_name_xor_ordinal( tcx: TyCtxt<'_>, codegen_fn_attrs: &CodegenFnAttrs, diff --git a/compiler/rustc_codegen_ssa/src/errors.rs b/compiler/rustc_codegen_ssa/src/errors.rs index e042fe1f819..9040915b6af 100644 --- a/compiler/rustc_codegen_ssa/src/errors.rs +++ b/compiler/rustc_codegen_ssa/src/errors.rs @@ -1108,22 +1108,6 @@ pub(crate) struct InvalidNoSanitize { pub span: Span, } -#[derive(Diagnostic)] -#[diag(codegen_ssa_invalid_link_ordinal_nargs)] -#[note] -pub(crate) struct InvalidLinkOrdinalNargs { - #[primary_span] - pub span: Span, -} - -#[derive(Diagnostic)] -#[diag(codegen_ssa_illegal_link_ordinal_format)] -#[note] -pub(crate) struct InvalidLinkOrdinalFormat { - #[primary_span] - pub span: Span, -} - #[derive(Diagnostic)] #[diag(codegen_ssa_target_feature_safe_trait)] pub(crate) struct TargetFeatureSafeTrait { -- cgit 1.4.1-3-g733a5