【咬文嚼字】2024S文档ch1中对于panic_handler的描述

[Andrew211vibe]

这里对panic_handler描述为一个语义项lang_item，但实际并不算语义项吧，在死灵书中描述" #[panic_handler] 用于定义 panic! 在 #![no_std] 程序中的行为"，并没有lang="xxx"的标识（如之后的会报错提示的eh_personality和start lang_item），应该只算依赖吧

翻看原v3文档对panic_handler解释的比较清楚：

#[panic_handler] 是一种编译指导属性，用于标记核心库core中的 panic! 宏要对接的函数（该函数实现对致命错误的具体处理）。该编译指导属性所标记的函数需要具有 fn(&PanicInfo) -> ! 函数签名，函数可通过 PanicInfo 数据结构获取致命错误的相关信息。这样Rust编译器就可以把核心库core中的 panic! 宏定义与 #[panic_handler] 指向的panic函数实现合并在一起，使得no_std程序具有类似std库的应对致命错误的功能

好玩儿的是在 https://github.com/rust-lang/rust/blob/master/compiler/rustc_hir/src/lang_items.rs 中的extract方法（extract lang_item方法连带着panic_handler一起extract了）

/// Extracts the first `lang = "$name"` out of a list of attributes.
/// The `#[panic_handler]` attribute is also extracted out when found.
pub fn extract(attrs: &[ast::Attribute]) -> Option<(Symbol, Span)> {
    attrs.iter().find_map(|attr| {
        Some(match attr {
            _ if attr.has_name(sym::lang) => (attr.value_str()?, attr.span),
            _ if attr.has_name(sym::panic_handler) => (sym::panic_impl, attr.span),
            _ => return None,
        })
    })
}

下面也有lang_item_table的定义，不过对于原v3文档的解释推敲一下感觉#[panic_handler]属性标记的就是panic_impl?
这就引出下面的core::panicking了

...

//! This module contains a few other panicking functions, but these are just the
//! necessary lang items for the compiler. All panics are funneled through this
//! one function. The actual symbol is declared through the `#[panic_handler]` attribute.

...

// First we define the two main entry points that all panics go through.
// In the end both are just convenience wrappers around `panic_impl`.

/// The entry point for panicking with a formatted message.
///
/// This is designed to reduce the amount of code required at the call
/// site as much as possible (so that `panic!()` has as low an impact
/// on (e.g.) the inlining of other functions as possible), by moving
/// the actual formatting into this shared place.
// If panic_immediate_abort, inline the abort call,
// otherwise avoid inlining because of it is cold path.
#[cfg_attr(not(feature = "panic_immediate_abort"), inline(never), cold)]
#[cfg_attr(feature = "panic_immediate_abort", inline)]
#[track_caller]
#[lang = "panic_fmt"] // needed for const-evaluated panics
#[rustc_do_not_const_check] // hooked by const-eval
#[rustc_const_unstable(feature = "panic_internals", issue = "none")]
pub const fn panic_fmt(fmt: fmt::Arguments<'_>) -> ! {
    if cfg!(feature = "panic_immediate_abort") {
        super::intrinsics::abort()
    }

    // NOTE This function never crosses the FFI boundary; it's a Rust-to-Rust call
    // that gets resolved to the `#[panic_handler]` function.
    extern "Rust" {
        #[lang = "panic_impl"]
        fn panic_impl(pi: &PanicInfo<'_>) -> !;
    }

    let pi = PanicInfo::internal_constructor(
        Some(&fmt),
        Location::caller(),
        /* can_unwind */ true,
        /* force_no_backtrace */ false,
    );

    // SAFETY: `panic_impl` is defined in safe Rust code and thus is safe to call.
    unsafe { panic_impl(&pi) }
}

...

NOTE: FFI(外部函数接口) boundary是指Rust代码和用另一种编程语言编写的代码之间的边界
英吹斯汀，"resolved to the #[panic_handler] function"，所以panic_handler其实应该是包含一个语义项实现还是就是解释为一个语义项呢？大家怎么看

[zjp-CN]

我倾向于认为更好的说法是“ panic_handler 提供语义项 (panic_impl)”。lang-items

    extern "Rust" {
        #[lang = "panic_impl"]
        fn panic_impl(pi: &PanicInfo<'_>) -> !;
    }

它首先是一个 builtin attribute, 用于定义 Rust 程序运行期间的 panic 的行为：

The panic_handler attribute can only be applied to a function with signature fn(&PanicInfo) -> !. The function marked with this attribute defines the behavior of panics.

src: https://doc.rust-lang.org/reference/runtime.html#the-panic_handler-attribute

然后，从 rustc 内部实现来看（也就是你找的那段代码），它其实可以被视为一个宽泛意义上的语义项：

The special panic_handler attribute is resolved via compiler/rustc_middle/src/middle/lang_items. The extract function converts the panic_handler attribute to a panic_impl lang item.

Now, we have a matching panic_handler lang item in the std. This function goes through the same process as the extern { fn panic_impl } definition in core, ending up with a symbol name of rust_begin_unwind. At link time, the symbol reference in core will be resolved to the definition of std (the function called begin_panic_handler in the Rust source).

src: https://rustc-dev-guide.rust-lang.org/panic-implementation.html?highlight=panic_handler#core-definition-of-panic

[Andrew211vibe]

确实是更好的说法，所以依据定义终究还只是个attribute，并不能直接称其为lang_item，2024S文档在这里的描述还是有些许误导的，不过v3中的解释我觉得也够了:)

[zjp-CN]

又稍微找了一下资料：

• stabilize #[panic_handler] rust-lang/rust#51366
• RFC 2070: panic-implementation
• Nomicon: panic-handler

既然 #[panic_handler] 和 #[lang = "panic_impl"] 等价，为什么需要前者呢? RFC 2070 里描述了动机，最重要的一句话是

a stable mechanism to specify the behavior of panic! in no-std context

其中：

• a stable mechanism: #[panic_handler] 可用于 stable Rust。这是因为定义 lang item 需要 nightly #![feature(lang_items)]
• in no-std context: 那么应用这个 #![feature(lang_items)] 会怎么样？Rust 不允许 no-std 环境下定义 lang_items

error: the feature `lang_items` is internal to the compiler or standard library
  --> src/main.rs:24:12
   |
24 | #![feature(lang_items)]
   |            ^^^^^^^^^^
   |
   = note: using it is strongly discouraged

从而也就能理解 core lib 只声明，但不能定义 panicking 的原因了 :)

core/panicking.rs
//! The core library cannot define panicking, but it does *declare* panicking. This
//! means that the functions inside of core are allowed to panic, but to be
//! useful an upstream crate must define panicking for core to use. The current
//! interface for panicking is: fn panic_impl(pi: &core::panic::PanicInfo<'_>) -> !

[Andrew211vibe]

看样子确实等价，rust-lang/rust#44489 (comment) 和 rust-lang/rust#66745 感觉就是目前相关的了，前者原文中对panic_impl和panic_handler的双重定义会产生冲突的测试给我CPU干烧了哈哈。那要这么说panic_handler虽然是attribute，但是desugar后就是lang_item panic_impl！那所以还是语义项了？不过或许就像如上所说，panic_handler是stable的（也就是说通过了类型检查的），而panic_fmt是unstable的，这个attribute和lang_item之间还是存在区别的，无论如何直接称panic_handler为语义项我觉得是不妥的。
另一个就是对于#![feature(lang_items)]的报错，只需要简单模仿添加#![allow(internal_features)]即可通过编译哈哈哈哈（虽然被标注不应该使用）