rust-lang/rust · error

FIXME(unsafe_binder)

Error message

FIXME(unsafe_binder)

What it means

An `unimplemented!("FIXME(unsafe_binder)")` ICE in the const-eval interpreter's value validator (`validity.rs`). When the validator walks a value whose type is `ty::UnsafeBinder`, it has no validation logic yet and panics. `UnsafeBinder` is an unstable in-progress language feature, so the const-eval path is explicitly marked unfinished.

Source

Thrown at compiler/rustc_const_eval/src/interpret/validity.rs:951

                    // pointer handling in `deref_pointer`.
                    if matches!(scalar, Scalar::Int(..)) {
                        self.ecx.clear_provenance(value)?;
                    }
                    self.add_data_range_place(value);
                }
                interp_ok(true)
            }
            ty::Never => {
                throw_validation_failure!(
                    self.path,
                    format!("encountered a value of the never type `!`")
                )
            }
            ty::Foreign(..) | ty::FnDef(..) => {
                // Nothing to check.
                interp_ok(true)
            }
            ty::UnsafeBinder(_) => unimplemented!("FIXME(unsafe_binder)"),
            // The above should be all the primitive types. The rest is compound, we
            // check them by visiting their fields/variants.
            ty::Adt(..)
            | ty::Tuple(..)
            | ty::Array(..)
            | ty::Slice(..)
            | ty::Str
            | ty::Dynamic(..)
            | ty::Closure(..)
            | ty::Pat(..)
            | ty::CoroutineClosure(..)
            | ty::Coroutine(..) => interp_ok(false),
            // Some types only occur during typechecking, they have no layout.
            // We should not see them here and we could not check them anyway.
            ty::Error(_)
            | ty::Infer(..)
            | ty::Placeholder(..)
            | ty::Bound(..)

View on GitHub (pinned to 7088e4b63a)

Solutions

  1. Do not use `unsafe binder` types in `const`/`static` initializers or other const-evaluated contexts; move them to runtime code.
  2. Disable the `unsafe_binder` feature gate for the affected crate.
  3. Update to a newer nightly where the FIXME is resolved; otherwise track the upstream issue.

Example fix

// before (unsafe binder in const -> ICE)
#![feature(unsafe_binder)]
const C: unsafe<'a> Wrap<'a, u8> = ...;

// after — keep unsafe binder out of const context
#![feature(unsafe_binder)]
fn make() -> unsafe<'a> Wrap<'a, u8> { ... }
Defensive patterns

Strategy: validation

Validate before calling

# Reject unsafe binder usage in const context before compiling
if rg -q 'feature(unsafe_binder)' src/ && rg -n 'const [A-Z_0-9]+:.*unsafe' src/; then
  echo "avoid: unsafe binder in const initializer triggers FIXME(unsafe_binder) in const-eval"
fi

Prevention

When it happens

Trigger: Const-evaluating or validating a constant (e.g. `const` item, array length, static initializer) whose type contains an `UnsafeBinder` (e.g. via the `unsafe binder` nightly feature's `Wrap<'a>`/binder types). The validity visitor reaches the `ty::UnsafeBinder(_)` arm at validity.rs:951.

Common situations: Experimenting with the unstable `unsafe binder` (`#![feature(unsafe_binder)]`) feature in const context — declaring a const whose type is or contains an unsafe binder, or running Miri/validation on such a value.

Related errors

AI-assisted analysis of rust-lang/rust@7088e4b63a (2026-08-10). Data as JSON: /api/errors/473c5582c2bc521c. Report an issue: GitHub.