[ICE]: "improper_ctypes: Option nonnull optimization not applied?"

[theemathas]

Code

#[repr(align(16))]
pub enum MyOption {
    Some(&'static ()),
    None,
}

pub extern "C" fn foo(_: MyOption) {}

See also #155412 and #88290

cc @RalfJung

Meta

Reproducible on the playground with version 1.97.0-nightly (2026-04-17 e9e32aca5a4ffd08cbc2)

Error output

error: internal compiler error: /rustc-dev/e9e32aca5a4ffd08cbc29547b039d64b92a2c03b/compiler/rustc_lint/src/types.rs:882:17: improper_ctypes: Option nonnull optimization not applied?

Backtrace

thread 'rustc' (27) panicked at /rustc-dev/e9e32aca5a4ffd08cbc29547b039d64b92a2c03b/compiler/rustc_lint/src/types.rs:882:17:
Box<dyn Any>
stack backtrace:
   0: std::panicking::begin_panic::<rustc_errors::ExplicitBug>
   1: <rustc_errors::diagnostic::BugAbort as rustc_errors::diagnostic::EmissionGuarantee>::emit_producing_guarantee
   2: rustc_middle::util::bug::opt_span_bug_fmt::<rustc_span::span_encoding::Span>::{closure#0}
   3: rustc_middle::ty::context::tls::with_opt::<rustc_middle::util::bug::opt_span_bug_fmt<rustc_span::span_encoding::Span>::{closure#0}, !>::{closure#0}
   4: rustc_middle::ty::context::tls::with_context_opt::<rustc_middle::ty::context::tls::with_opt<rustc_middle::util::bug::opt_span_bug_fmt<rustc_span::span_encoding::Span>::{closure#0}, !>::{closure#0}, !>
   5: rustc_middle::util::bug::bug_fmt
   6: rustc_lint::types::repr_nullable_ptr.cold
   7: <rustc_lint::types::improper_ctypes::ImproperCTypesVisitor>::visit_type
   8: <rustc_lint::types::improper_ctypes::ImproperCTypesVisitor>::check_type
   9: <rustc_lint::types::improper_ctypes::ImproperCTypesLint>::check_foreign_fn
  10: <rustc_lint::BuiltinCombinedModuleLateLintPass as rustc_lint::passes::LateLintPass>::check_fn
  11: <rustc_lint::late::LateContextAndPass<rustc_lint::BuiltinCombinedModuleLateLintPass> as rustc_hir::intravisit::Visitor>::visit_nested_item
  12: rustc_lint::lint_mod
  13: rustc_query_impl::execution::try_execute_query::<rustc_middle::query::caches::DefaultCache<rustc_span::def_id::LocalModDefId, rustc_middle::query::erase::ErasedData<[u8; 0]>>, false>
  14: rustc_lint::late::check_crate::{closure#1}
  15: rustc_lint::late::check_crate
  16: rustc_interface::passes::analysis::{closure#0}::{closure#0}::{closure#2}
  17: rustc_data_structures::sync::parallel::par_fns
  18: rustc_interface::passes::analysis::{closure#0}::{closure#0}
  19: rustc_data_structures::sync::parallel::par_fns
  20: rustc_interface::passes::analysis
  21: rustc_query_impl::execution::try_execute_query::<rustc_middle::query::caches::SingleCache<rustc_middle::query::erase::ErasedData<[u8; 0]>>, false>
  22: rustc_interface::interface::run_compiler::<(), rustc_driver_impl::run_compiler::{closure#0}>::{closure#1}
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: please make sure that you have updated to the latest nightly

note: please attach the file at `/playground/rustc-ice-2026-04-18T08_56_39-25.txt` to your bug report

note: rustc 1.97.0-nightly (e9e32aca5 2026-04-17) running on x86_64-unknown-linux-gnu

note: compiler flags: --crate-type lib -C embed-bitcode=no -C codegen-units=1 -C debuginfo=2

note: some of the compiler flags provided by cargo are hidden

query stack during panic:
#0 [lint_mod] linting top-level module
#1 [analysis] running analysis passes on crate `playground`
end of query stack
error: could not compile `playground` (lib)

[RalfJung]

This is sharing logic with the transmute check. Is the ICE fixed by #155418?

[theemathas]

@RalfJung I haven't tested, but I would be surprised if that PR fixed this issue, since all the relevant types are non-generic, and therefore have statically-known layouts, and therefore uses the special case in the beginning of SizeSkeleton::compute.

The actually relevant logic is at https://github.com/rust-lang/rust/blob/main/compiler/rustc_lint/src/types.rs#L853-L871

[RalfJung]

Okay, if the bug is in the lint then that's outside my wheelhouse... I know there's tons of problems with the lint but I haven't had the time to even start thinking about a cleanup.^^

Cc @workingjubilee

[theemathas]

cc @niacdoial (author of #146275)

[niacdoial]

oh, I see what's happening.
the lint sees a OptionLikeEnum<NonNullType>, and so it assumes that the enum and its inner type have the same size.
...but I guess that "Not having a separate discriminant" and "having the same size as the inner type" are not the same thing.

I... somehow have not thought about this #[repr(align(N))] thing when working on that lint, sorry about that. (I didn't even know it existed, I'll have to look its semantics up)
Is I want this alignment something you can even do in C?

... in any case, I see a few options right now:

• not do anything right now, and just put this consideration into the work being done on the lint
  (that PR above, which I think will need a discussion with the appropriate team because there are quite a few changes in what the lint says and doesn't say)
  (most likely the worst option, given how easy the next two are)
• bandaid fix that (for now) assumes these aligned reprs make things FFI-unsafe, and then think about it some more
• bandaid fix that just ignores this, to err on the side of false negatives when working with lints
  (easiest solution to implement, a probably-literal one-line-fix)
• determine when repr(align(N)) is FFI-safe (eg: if it lands on the same alignment as C would want) and push this as a separate fix to the lint