ICE: NormalizationError during linting

[saethlin]

Code

https://github.com/memflow/memflow/ at ec4d19b5600597d0f9e463c3ad085af288f77f5c

Error output

called `Result::unwrap()` on an `Err` value: NormalizationFailure(std::option::Option<&<T as plugins::Loadable>::ArgsType>, Type(std::option::Option<&<T as plugins::Loadable>::ArgsType>))

Backtrace

thread 'rustc' panicked at compiler/rustc_lint/src/types.rs:920:82:
called `Result::unwrap()` on an `Err` value: NormalizationFailure(std::option::Option<&<T as plugins::Loadable>::ArgsType>, Type(std::option::Option<&<T as plugins::Loadable>::ArgsType>))
stack backtrace:
   0: rust_begin_unwind
             at /rustc/c469197b19d53a6c45378568f73c00986b20a5a5/library/std/src/panicking.rs:617:5
   1: core::panicking::panic_fmt
             at /rustc/c469197b19d53a6c45378568f73c00986b20a5a5/library/core/src/panicking.rs:67:14
   2: core::result::unwrap_failed
             at /rustc/c469197b19d53a6c45378568f73c00986b20a5a5/library/core/src/result.rs:1652:5
   3: rustc_lint::types::repr_nullable_ptr
   4: <rustc_lint::types::ImproperCTypesVisitor>::check_type_for_ffi
   5: <rustc_lint::types::ImproperCTypesVisitor>::check_type_for_ffi
   6: <rustc_lint::types::ImproperCTypesVisitor>::check_type_for_ffi_and_report_errors
   7: <rustc_lint::types::ImproperCTypesDefinitions>::check_ty_maybe_containing_foreign_fnptr
   8: <rustc_lint::BuiltinCombinedModuleLateLintPass as rustc_lint::passes::LateLintPass>::check_item
   9: rustc_hir::intravisit::walk_mod::<rustc_lint::late::LateContextAndPass<rustc_lint::BuiltinCombinedModuleLateLintPass>>
  10: rustc_lint::late::late_lint_mod::<rustc_lint::BuiltinCombinedModuleLateLintPass>
  11: rustc_lint::lint_mod
      [... omitted 2 frames ...]
  12: rustc_data_structures::sync::par_for_each_in::<&[rustc_hir::hir_id::OwnerId], <rustc_middle::hir::map::Map>::par_for_each_module<rustc_lint::late::check_crate::{closure#1}::{closure#0}::{closure#0}>::{closure#0}>
  13: <rustc_session::session::Session>::time::<(), rustc_lint::late::check_crate::{closure#1}::{closure#0}>
  14: <core::panic::unwind_safe::AssertUnwindSafe<rustc_interface::passes::analysis::{closure#5}::{closure#1}::{closure#2}> as core::ops::function::FnOnce<()>>::call_once
  15: <core::panic::unwind_safe::AssertUnwindSafe<rustc_interface::passes::analysis::{closure#5}::{closure#1}> as core::ops::function::FnOnce<()>>::call_once
  16: <rustc_session::session::Session>::time::<(), rustc_interface::passes::analysis::{closure#5}>
  17: rustc_interface::passes::analysis
      [... omitted 2 frames ...]
  18: <rustc_interface::queries::QueryResult<&rustc_middle::ty::context::GlobalCtxt>>::enter::<core::result::Result<(), rustc_span::ErrorGuaranteed>, rustc_driver_impl::run_compiler::{closure#1}::{closure#2}::{closure#6}>
  19: <rustc_interface::interface::Compiler>::enter::<rustc_driver_impl::run_compiler::{closure#1}::{closure#2}, core::result::Result<core::option::Option<rustc_interface::queries::Linker>, rustc_span::ErrorGuaranteed>>
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

error: the compiler unexpectedly panicked. this is a bug.

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 attach the file at `/root/build/rustc-ice-2023-08-23T12:46:10.422852522Z-1639.txt` to your bug report

note: compiler flags: --crate-type lib -C embed-bitcode=no -C debuginfo=2 -C opt-level=0 -Z validate-mir -Z randomize-layout -C debuginfo=0

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

query stack during panic:
#0 [lint_mod] linting module `plugins`
#1 [analysis] running analysis passes on this crate
end of query stack

searched nightlies: from nightly-2023-01-01 to nightly-2023-08-14
regressed nightly: nightly-2023-07-04
searched commit range: 839e9a6...0ab38e9
regressed commit: 0ab38e9

bisected with cargo-bisect-rustc v0.6.6

Host triple: x86_64-unknown-linux-gnu
Reproduce with:

cargo bisect-rustc --start 2023-01-01 --end 2023-08-14 -- check 

[ko1N]

As referenced in the other issue this now also happens on stable since >= 1.70. The culprint seems to be this type alias:

pub type CreateFn<T> = extern "C" fn(
    Option<&<T as Loadable>::ArgsType>,
    <T as Loadable>::CInputArg,
    lib: LibArc,
    logger: Option<&'static PluginLogger>,
    &mut MaybeUninit<<T as Loadable>::Instance>,
) -> i32;

pub trait Loadable: Sized {
    type Instance: StableAbi;
    type InputArg;
    type CInputArg: StableAbi;
    type ArgsType;

...
}

Removing the reference in the Option works around this panic.

[ko1N]

Here's a minimal example that reproduces the issue:

pub type SomeFn<T> = extern "C" fn(
    Option<&<T as SomeTrait>::SomeType>,
);

pub trait SomeTrait {
    type SomeType;
}

Interestingly, this only happens while the function is extern "C".

[apiraino]

WG-prioritization assigning priority (Zulip discussion).

cc: @davidtwco for the bisection pointing to 0ab38e9

@rustbot label -I-prioritize +P-high

[gurry]

@rustbot claim

[gurry]

The panic originates in the unwrap() on this line:

rust/compiler/rustc_lint/src/types.rs

Line 920 in 3d24970

let compute_size_skeleton = |t| SizeSkeleton::compute(t, tcx, param_env).unwrap();

It happens because SizeSkeleton::compute() returns None which it does because normalization of std::option::Option<&<T as SomeTrait>::SomeType> fails. The reason the normalization fails is because trait resolution fails for the projection T as SomeTrait due to T not being sufficiently bound. If, for example, I change pub type SomeFn<T> = ... in @ko1N 's example above to pub type SomeFn<T: SomeTrait> = ... by adding a bound, the panic goes away as trait resolution succeeds now.

Since the normalization failure can be legitimate as in this case, I feel this unwrap:

rust/compiler/rustc_lint/src/types.rs

Line 920 in 3d24970

let compute_size_skeleton = |t| SizeSkeleton::compute(t, tcx, param_env).unwrap();

should be removed to fix the issue. However, I'm not sure what the enclosing method repr_nullable_ptr() should do upon receiving a None from SizeSkeleton::compute(). I'd presume it should return None.

Please review and let me know if this analysis makes sense.

cc: @davidtwco

[gurry]

Closely related PR: #115631 . It fixes an ICE due to similar causes but on a different line. In fact the very next line.

[compiler-errors]

@gurry Yeah, I think making compute_size_skeleton not unwrap() and just bubble up the None is the right behavior here.