rustdoc-json: `#[target_feature]` incorrectly causes safe functions to be listed as `unsafe`

[obi1kenobi]

I tried this code:

#[target_feature(enable = "sse2")]
pub fn compute(x: u32) -> u32 {
    x + 1
}

I expected to see this happen: rustdoc JSON should contain an entry for compute whose header field says:

"header": {
    "is_const": false,
    "is_unsafe": false,
    "is_async": false,
    "abi": "Rust"
},

Instead, this happened: the rustdoc JSON entry for compute incorrectly lists it as unsafe. Here's its entire item entry from a format_version: 46 rustdoc JSON file:

"0": {
    "id": 0,
    "crate_id": 0,
    "name": "compute",
    "span": {
        "filename": "src/lib.rs",
        "begin": [
            2,
            1
        ],
        "end": [
            4,
            2
        ]
    },
    "visibility": "public",
    "docs": null,
    "links": {},
    "attrs": [
        "#[target_feature(enable = \"sse2\")]"
    ],
    "deprecation": null,
    "inner": {
        "function": {
            "sig": {
                "inputs": [
                    [
                        "x",
                        {
                            "primitive": "u32"
                        }
                    ]
                ],
                "output": {
                    "primitive": "u32"
                },
                "is_c_variadic": false
            },
            "generics": {
                "params": [],
                "where_predicates": []
            },
            "header": {
                "is_const": false,
                "is_unsafe": true,  # <--- BUG!
                "is_async": false,
                "abi": "Rust"
            },
            "has_body": true
        }
    }
},

Meta

rustc --version --verbose:

rustc 1.89.0-nightly (45acf54ee 2025-06-16)
binary: rustc
commit-hash: 45acf54eea118ed27927282b5e0bfdcd80b7987c
commit-date: 2025-06-16
host: x86_64-unknown-linux-gnu
release: 1.89.0-nightly
LLVM version: 20.1.5

@rustbot label +A-rustdoc-json

cc @aDotInTheVoid

[obi1kenobi]

The same issue happens with safe inherent associated functions. Of the non-unsafe cases, #[target_feature] can only be applied to safe free and inherent associated functions, and cannot be applied to safe trait functions, so that's the entire set of cases to look at.

This is causing false-positives in cargo-semver-checks lints function_unsafe_added and inherent_method_unsafe_added.

[workingjubilee]

@obi1kenobi these functions are unsafe to call though?

[aDotInTheVoid]

They can be called safely in other #[target_feature] functions, unless they're marked as unsafe. Playground

#[target_feature(enable = "sse2")]
pub fn safe_if_sse2(x: u32) -> u32 {
    x + 1
}

#[target_feature(enable = "sse2")]
pub unsafe fn unsafe_even_if_sse2(x: u32) -> u32 {
    x + 1
}

#[target_feature(enable = "sse2")]
pub fn entry() {
    safe_if_sse2(1); // Fine
    unsafe_even_if_sse2(1); // Error!
}

error[E0133]: call to unsafe function `unsafe_even_if_sse2` is unsafe and requires unsafe block
  --> src/lib.rs:14:5
   |
14 |     unsafe_even_if_sse2(1); // Error!
   |     ^^^^^^^^^^^^^^^^^^^^^^ call to unsafe function
   |

[obi1kenobi]

This is new in Rust 1.86, which is how I first even learned this feature exists at all :)

https://blog.rust-lang.org/2025/04/03/Rust-1.86.0/#allow-safe-functions-to-be-marked-with-the-target-feature-attribute

[workingjubilee]

I know about that, I was more wondering about the implementation...

Actually I left a comment in that issue.

[aDotInTheVoid]

Why does this happen:

rustdoc-json gets it's unsafey information from HIR (rustc_hir::FnHeader):

rust/src/librustdoc/json/conversions.rs

Lines 362 to 366 in 27eb269

	pub(crate) fn from_fn_header(header: &rustc_hir::FnHeader) -> FunctionHeader {
	FunctionHeader {
	is_async: header.is_async(),
	is_const: header.is_const(),
	is_unsafe: header.is_unsafe(),

This stores safety as a HeaderSafety

rust/compiler/rustc_hir/src/hir.rs

Lines 4259 to 4260 in 27eb269

	pub struct FnHeader {
	pub safety: HeaderSafety,

HeaderSafety models a tri-state of either Safe, Unsafe, or Safe but marked as #[target_feature]

rust/compiler/rustc_hir/src/hir.rs

Lines 4242 to 4250 in 27eb269

	pub enum HeaderSafety {
	/// A safe function annotated with `#[target_features]`.
	/// The type system treats this function as an unsafe function,
	/// but safety checking will check this enum to treat it as safe
	/// and allowing calling other safe target feature functions with
	/// the same features without requiring an additional unsafe block.
	SafeTargetFeatures,
	Normal(Safety),
	}

rust/compiler/rustc_hir/src/hir.rs

Lines 4186 to 4189 in 27eb269

	pub enum Safety {
	Unsafe,
	Safe,
	}

However, this .is_unsafe() method on FnHeader considers Safe but marked as #[target_feature] to be safe. This is probably the correct choice for safety-checking, but is wrong for rustdoc.

rust/compiler/rustc_hir/src/hir.rs

Lines 4275 to 4288 in 27eb269

	pub fn is_unsafe(&self) -> bool {
	self.safety().is_unsafe()
	}
	pub fn is_safe(&self) -> bool {
	self.safety().is_safe()
	}
	pub fn safety(&self) -> Safety {
	match self.safety {
	HeaderSafety::SafeTargetFeatures => Safety::Unsafe,
	HeaderSafety::Normal(safety) => safety,
	}
	}

How to fix

rust/src/librustdoc/json/conversions.rs

Lines 362 to 366 in 27eb269

	pub(crate) fn from_fn_header(header: &rustc_hir::FnHeader) -> FunctionHeader {
	FunctionHeader {
	is_async: header.is_async(),
	is_const: header.is_const(),
	is_unsafe: header.is_unsafe(),

should be changed to consider SafeTargetFeatures as safe.

Related Work

These are needed to fix this issue, but are worth looking at:

• The methods on HIR are kinda footgunny. Having docs that explain the subtleties on them would be nice.
  • Potentially the could be removed entirely, and get replaced with forcing people to match, and consider that safety is a tri-state.
  • Treat safe target_feature functions as unsafe by default [less invasive variant] #134353 has context for why things are the way they are.
• HTML probably gets this wrong. But it'll take more work to decide what the right thing is. This should be it's own issue, where the right UI can be decided.