Complex generic constants cause 'not user writable' panic when invoked by rustdoc

[zeyonaut]

Code

#![feature(const_generics, const_evaluatable_checked)]
#![allow(incomplete_features)]
struct A<T, const N: core::num::NonZeroUsize>([T; N.get()]) where [T; N.get()]: Sized;

Meta

rustc --version --verbose:

rustc 1.49.0-nightly (98edd1fbf 2020-10-06)
binary: rustc
commit-hash: 98edd1fbf8a68977a2a7c1312eb1ebff80515a92
commit-date: 2020-10-06
host: x86_64-pc-windows-msvc
release: 1.49.0-nightly
LLVM version: 11.0

Error output

cargo doc

thread 'rustc' panicked at 'not user writable', src\librustdoc\clean\mod.rs:512:63
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

error: internal compiler error: unexpected panic

error: Unrecognized option: 'crate-version'

error: could not document `bugtest`

Backtrace

stack backtrace:
   0:     0x7ff948f79859 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::hc20a26e0f7659afd
   1:     0x7ff948fa6f8b - core::fmt::write::h435be716304d26a1
   2:     0x7ff948f6b1d8 - <std::io::IoSlice as core::fmt::Debug>::fmt::h997d94c78f1ba97b
   3:     0x7ff948f7ec44 - std::panicking::take_hook::hbf7e33d26fc3ca30
   4:     0x7ff948f7e828 - std::panicking::take_hook::hbf7e33d26fc3ca30
   5:     0x7ff903296257 - rustc_driver::report_ice::hf0a13013cc3176ab
   6:     0x7ff948f7f6a0 - std::panicking::rust_panic_with_hook::h19068ccbe4b337a1
   7:     0x7ff6e4f92ca4 - <unknown>
   8:     0x7ff6e4f921bf - <unknown>
   9:     0x7ff6e4df193d - <unknown>
  10:     0x7ff6e5060f92 - <unknown>
  11:     0x7ff6e5090644 - <unknown>
  12:     0x7ff6e50629ac - <unknown>
  13:     0x7ff6e4ebc376 - <unknown>
  14:     0x7ff6e4ed8b14 - <unknown>
  15:     0x7ff6e4f3ae47 - <unknown>
  16:     0x7ff6e4e9d692 - <unknown>
  17:     0x7ff6e509632d - <unknown>
  18:     0x7ff6e50cd1b8 - <unknown>
  19:     0x7ff6e4ddeb6c - <unknown>
  20:     0x7ff6e508f0a7 - <unknown>
  21:     0x7ff6e4dce6c0 - <unknown>
  22:     0x7ff6e4dde7bf - <unknown>
  23:     0x7ff6e4dd8c1f - <unknown>
  24:     0x7ff6e4d95ea8 - <unknown>
  25:     0x7ff6e4ee10c9 - <unknown>
  26:     0x7ff6e4e975f5 - <unknown>
  27:     0x7ff6e4ee2fe4 - <unknown>
  28:     0x7ff6e4de6488 - <unknown>
  29:     0x7ff6e4ed575c - <unknown>
  30:     0x7ff6e4f9284b - <unknown>
  31:     0x7ff6e50b7413 - <unknown>
  32:     0x7ff948f8f577 - std::sys::windows::thread::Thread::new::h04914a10b014a9d7
  33:     0x7ff99b6c7bd4 - BaseThreadInitThunk
  34:     0x7ff99d2ace51 - RtlUserThreadStart

[ghost]

Related: #77645

[jyn514]

@lcnr do you know what's going on here? The rustdoc code is

rust/src/librustdoc/clean/mod.rs

Lines 506 to 512 in 0dda415

	ty::PredicateAtom::Subtype(..)
	| ty::PredicateAtom::WellFormed(..)
	| ty::PredicateAtom::ObjectSafe(..)
	| ty::PredicateAtom::ClosureKind(..)
	| ty::PredicateAtom::ConstEvaluatable(..)
	| ty::PredicateAtom::ConstEquate(..)
	| ty::PredicateAtom::TypeWellFormedFromEnv(..) => panic!("not user writable"),

[lcnr]

Yeah, that one's somewhat expected. const_evaluatable_checked adds ConstEvaluatable predicates to predicates_of, so we now have to deal with them in rustdoc, can fix this myself next week

[androm3da]

I minimized the failure I'm seeing in rustdoc and it looks like it's this issue and not a separate one. Is there any workaround or is any const_evaluatable_checked expected to see this breakage w/rustdoc?

#![feature(const_evaluatable_checked)]
#![allow(incomplete_features)]

const fn a() -> usize {
    0
}
struct B
where
    [(); a()]: ;

[jyn514]

No, there's no workaround that I know of. I don't understand the implementation of const generics very well, nor does anyone else on the team.

[PiDelport]

Does anyone know what would be needed to fix this, or at least work around it enough to stop rustdoc from crashing?

(This is currently disabling rustdoc for our project, which relies on some const_evaluatable_checked code.)