Some UnevaluatedConst are not monomorphised

[dkcumming]

We can observe that some attempts to monomorphise an UnevaluatedConst with rustc_middle::ty::Instance::try_resolve will return Ok(None) which we panic on when trying to retrieve the Instance.

When compiling p-token the dependency memchr is required, however attempting to compile with create the following error (Some extra printing added):

daniel@daniel-MS-7E06 p-token$ RUSTC=~/.stable-mir-json/release.sh cargo build -p token-program --release
   Compiling proc-macro2 v1.0.86
   Compiling memchr v2.7.4
   Compiling unicode-ident v1.0.13
   Compiling regex-syntax v0.8.4
   Compiling syn v1.0.109

thread 'rustc' has overflowed its stack
fatal runtime error: stack overflow

thread 'rustc' has overflowed its stack
fatal runtime error: stack overflow
thread 'rustc' panicked at src/printer.rs:837:21:
Failed to resolve mono item for UnevaluatedConst { def: ConstDef(DefId { id: 171, name: "vector::Vector::BYTES" }), args: GenericArgs([Type(Ty { id: 343, kind: Param(ParamTy { index: 0, name: "V" }) })]), promoted: None }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
error: could not compile `memchr` (lib)

Caused by:
  process didn't exit successfully: `/home/daniel/.stable-mir-json/release.sh --crate-name memchr --edition=2021 /home/daniel/.cargo/registry/src/index.crates.io-6f17d22bba15001f/memchr-2.7.4/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --diagnostic-width=94 --crate-type lib --emit=dep-info,metadata,link -C embed-bitcode=no -C debug-assertions=off --cfg 'feature="alloc"' --cfg 'feature="std"' --check-cfg 'cfg(docsrs)' --check-cfg 'cfg(feature, values("alloc", "compiler_builtins", "core", "default", "libc", "logging", "rustc-dep-of-std", "std", "use_std"))' -C metadata=c8965d0a91d5998f -C extra-filename=-c8965d0a91d5998f --out-dir /home/daniel/Applications/p-token/target/release/deps -C strip=debuginfo -L dependency=/home/daniel/Applications/p-token/target/release/deps --cap-lints allow` (exit status: 101)
warning: build failed, waiting for other jobs to finish...

I suspect this is related to a constant of a struct relying on an associated constant of an implemented trait. We may be organising the items and attempting monomorphisation in an order that is impossible.

Some extra information from rustc_middle::ty::Instance::try_resolve:

/// Presuming that coherence and type-check have succeeded, if this method is invoked
/// in a monomorphic context (i.e., like during codegen), then it is guaranteed to return
/// Ok(Some(instance)), except for when the instance's inputs hit the type size limit,
/// in which case it may bail out and return Ok(None).