#[rustc_layout(debug)] ICEs when applied to some type aliases

[camelid]

Code

(Playground)

#![feature(rustc_attrs)]

use std::borrow::Cow;

#[rustc_layout(debug)]
type Edges<'a, E> = Cow<'a, [E]>;

ICE

error: internal compiler error: compiler/rustc_traits/src/normalize_erasing_regions.rs:54:32: could not fully normalize `<[E] as std::borrow::ToOwned>::Owned`

thread 'rustc' panicked at 'Box<Any>', /rustc/770792ff8d1ec542e78e77876ac936f43ffb8e05/library/std/src/panic.rs:59:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

note: 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: rustc 1.54.0-nightly (770792ff8 2021-05-07) running on x86_64-unknown-linux-gnu

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

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

query stack during panic:
#0 [normalize_generic_arg_after_erasing_regions] normalizing `<[E] as std::borrow::ToOwned>::Owned`
#1 [layout_raw] computing layout of `std::borrow::Cow<[E]>`
end of query stack
error: aborting due to previous error

error: could not compile `playground`

To learn more, run the command again with --verbose.

Backtrace

thread 'rustc' panicked at 'Box<Any>', /rustc/770792ff8d1ec542e78e77876ac936f43ffb8e05/library/std/src/panic.rs:59:5
stack backtrace:
   0: std::panicking::begin_panic
   1: std::panic::panic_any
   2: rustc_errors::HandlerInner::bug
   3: rustc_errors::Handler::bug
   4: rustc_middle::ty::context::tls::with_opt
   5: rustc_middle::util::bug::opt_span_bug_fmt
   6: rustc_middle::util::bug::bug_fmt
   7: rustc_infer::infer::InferCtxtBuilder::enter
   8: core::ops::function::FnOnce::call_once
   9: rustc_query_system::dep_graph::graph::DepGraph<K>::with_task_impl
  10: rustc_data_structures::stack::ensure_sufficient_stack
  11: rustc_query_system::query::plumbing::force_query_with_job
  12: rustc_query_system::query::plumbing::get_query_impl
  13: <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::normalize_generic_arg_after_erasing_regions
  14: <rustc_middle::ty::normalize_erasing_regions::NormalizeAfterErasingRegionsFolder as rustc_middle::ty::fold::TypeFolder>::fold_ty
  15: <rustc_middle::ty::layout::LayoutCx<rustc_middle::ty::context::TyCtxt> as rustc_target::abi::LayoutOf>::layout_of
  16: <alloc::vec::Vec<T> as alloc::vec::spec_from_iter::SpecFromIter<T,I>>::from_iter
  17: <alloc::vec::Vec<T> as alloc::vec::spec_from_iter::SpecFromIter<T,I>>::from_iter
  18: core::iter::adapters::process_results
  19: rustc_middle::ty::layout::LayoutCx<rustc_middle::ty::context::TyCtxt>::layout_raw_uncached
  20: rustc_middle::ty::layout::layout_raw
  21: rustc_query_impl::<impl rustc_query_system::query::config::QueryAccessors<rustc_query_impl::plumbing::QueryCtxt> for rustc_query_impl::queries::layout_raw>::compute
  22: rustc_query_system::dep_graph::graph::DepGraph<K>::with_task_impl
  23: rustc_data_structures::stack::ensure_sufficient_stack
  24: rustc_query_system::query::plumbing::force_query_with_job
  25: rustc_query_system::query::plumbing::get_query_impl
  26: <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::layout_raw
  27: <rustc_middle::ty::layout::LayoutCx<rustc_middle::ty::context::TyCtxt> as rustc_target::abi::LayoutOf>::layout_of
  28: <rustc_passes::layout_test::LayoutTest as rustc_hir::itemlikevisit::ItemLikeVisitor>::visit_item
  29: rustc_hir::hir::Crate::visit_all_item_likes
  30: rustc_passes::layout_test::test_layout
  31: rustc_interface::passes::analysis
  32: rustc_query_system::dep_graph::graph::DepGraph<K>::with_task_impl
  33: rustc_data_structures::stack::ensure_sufficient_stack
  34: rustc_query_system::query::plumbing::force_query_with_job
  35: rustc_query_system::query::plumbing::get_query_impl
  36: <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::analysis
  37: rustc_interface::passes::QueryContext::enter
  38: rustc_interface::queries::<impl rustc_interface::interface::Compiler>::enter
  39: rustc_span::with_source_map
  40: rustc_interface::interface::create_compiler_and_run
  41: scoped_tls::ScopedKey<T>::set

Background information

This is a minimization of a bug encountered in #83501. Rustdoc wants to show memory layout info for type aliases (see 78d4b453ad2e19d44011b26fc55c949bff5dba3d for an explanation of why we want to show it for type aliases in particular), but building the compiler docs failed (which probably means that many other crates would fail as well). The type alias that caused the ICE is rustc_graphviz::Edges, which (fortunately) can be extracted into an MCVE without any other dependencies. That is the MCVE that I used for this issue.

[LeSeulArtichaut]

Minimized further:

#![feature(rustc_attrs)]

trait Foo {
    type Bar;
}

#[rustc_layout(debug)]
type Edges<E> = <E as Foo>::Bar;

[apiraino]

Bisection seems to point to somewhere to an old nightly-2019-01-27

$ cargo-bisect-rustc --preserve --start=2019-01-01 --regress error

found 8 bors merge commits in the specified range
  commit[0] 2019-01-25UTC: Auto merge of #57435 - Dylan-DPC:fi/compiler-builtins-lock, r=alexcrichton
  commit[1] 2019-01-25UTC: Auto merge of #57898 - Centril:rollup, r=Centril
  commit[2] 2019-01-26UTC: Auto merge of #57675 - cuviper:llvm-monorepo, r=alexcrichton
  commit[3] 2019-01-26UTC: Auto merge of #55641 - nagisa:optimize-attr, r=pnkfelix
  commit[4] 2019-01-26UTC: Auto merge of #57425 - alexcrichton:stabilize-atomics, r=sfackler
  commit[5] 2019-01-26UTC: Auto merge of #57726 - Zoxc:combine-early-lints, r=estebank
  commit[6] 2019-01-26UTC: Auto merge of #57852 - davidtwco:issue-57819, r=estebank
  commit[7] 2019-01-26UTC: Auto merge of #57918 - Centril:rollup, r=Centril
ERROR: no commits between bf669d1e3295bc688f71b8c91f48a6beaf895f67 and 
    20c2cba61dc83e612d25ed496025171caa3db30f within last 167 days

[camelid]

$ cargo-bisect-rustc --preserve --start=2019-01-01 --regress error

Hmm, shouldn't this be --regress ice?

[apiraino]

$ cargo-bisect-rustc --preserve --start=2019-01-01 --regress error

Hmm, shouldn't this be --regress ice?

ah yes, definitively. I think it's just a typo copying the command here 😅 because with --regress ice I have the same result (but feel free to double check)

[LeSeulArtichaut]

Also got the same results with cargo-bisect-rustc --preserve --start=2019-01-01 --end=2019-02-01 --regress=ice -- check.

[LeSeulArtichaut]

Oh, #[rustc_layout] was introduced in nightly-2019-01-27 (#57645) so either the implementation of #[rustc_layout] is wrong, or there is an underlying bug that predates 2021-01-27

[LeSeulArtichaut]

From the little evidence I gathered, I think I know why this ICEs. Here's an example that makes this obvious:

// () does not implement Foo

type AlwaysInvalid = <() as Foo>::Bar; // no error...

struct Baz {
    baz: AlwaysInvalid // ...until it is used: only now will the compiler complain about (): Foo not being satisfied
}

By applying #[rustc_layout(debug)] we force normalization to happen, but we haven't ran type-checking so normalization just fails. On the other hand, we need to normalize valid things like:

#[rustc_layout(debug)]
type Tea<'a> = <&'a [u32] as IntoIterator>::IntoIter;

@camelid For your use case in rustdoc, I'm assuming you'd want to have a "layout error" instead of an ICE for things like AlwaysInvalid?

[camelid]

From the little evidence I gathered, I think I know why this ICEs. Here's an example that makes this obvious:

// () does not implement Foo

type AlwaysInvalid = <() as Foo>::Bar; // no error...

struct Baz {
    baz: AlwaysInvalid // ...until it is used: only now will the compiler complain about (): Foo not being satisfied
}

By applying #[rustc_layout(debug)] we force normalization to happen, but we haven't ran type-checking so normalization just fails. On the other hand, we need to normalize valid things like:

#[rustc_layout(debug)]
type Tea<'a> = <&'a [u32] as IntoIterator>::IntoIter;

@camelid For your use case in rustdoc, I'm assuming you'd want to have a "layout error" instead of an ICE for things like AlwaysInvalid?

Ah, that makes sense! Thanks for looking into this :)

And yes, I think it would be helpful for my use case if it gave a layout error instead of an ICE. If I write a struct with the appropriate constraint, I get a LayoutError::Unknown, which makes sense:

#[rustc_layout(debug)]
struct Edges<'a, E>(Cow<'a, [E]>) where [E]: ToOwned;

error: layout error: Unknown(<[E] as std::borrow::ToOwned>::Owned)
 --> src/lib.rs:6:1
  |
6 | struct Edges<'a, E>(Cow<'a, [E]>) where [E]: ToOwned;
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to previous error

Though for the normalization error maybe we should have a new LayoutError variant called FailedNormalization or Unnormalized or something like that? By the way, it's probably worth asking some people familiar with the layout and normalization code to see what they think before starting on an implementation.

[apiraino]

Assigning priority as discussed in the Zulip thread of the Prioritization Working Group.

@rustbot label -I-prioritize +P-medium

edit: better a @rustbot label +P-high -P-medium

[LeSeulArtichaut]

I'll try to work on this.

[jyn514]

I'm moving this back down to P-medium, this only blocks new features and isn't a regression.