Change:
match ty.kind { ty::FnPtr(_) => true, ty::Ref(..) => true, <del> ty::Adt(field_def, substs) if field_def.repr.transparent() && !field_def.is_union() => { for field in field_def.all_fields() { let field_ty = self.cx.tcx.normalize_erasing_regions( self.cx.param_env, field.ty(self.cx.tcx, substs), ); if field_ty.is_zst(self.cx.tcx, field.did) { continue; } </del> <ins> ty::Adt(def, substs) if def.repr.transparent() && !def.is_union() => { let guaranteed_nonnull_optimization = self .cx .tcx .get_attrs(def.did) .iter() .any(|a| a.check_name(sym::rustc_nonnull_optimization_guaranteed)); if guaranteed_nonnull_optimization { return true; } </ins> <del> let attrs = self.cx.tcx.get_attrs(field_def.did); if attrs .iter() .any(|a| a.check_name(sym::rustc_nonnull_optimization_guaranteed)) || self.ty_is_known_nonnull(field_ty) { return true; </del> <ins> for variant in &def.variants { if let Some(field) = variant.transparent_newtype_field(self.cx.tcx) { if self.ty_is_known_nonnull(field.ty(self.cx.tcx, substs)) { return true; } </ins> } }

Discussion:
On the latest nightly (2020-06-25), a small usage of the crate causes an ICE when trying to compile even a small example. I confirmed that the past week of nightly releases compile fine before the latest. On the latest stable (1.44.1) this compiles just fine as expected. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Let’s try to find an MCVE. I’d also like to find the culprit PR, which shouldn’t take too long since we know in which nightly this regressed. ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
Just tried this out locally as well and can confirm the ICE happens.. time to dig in ..
ping windows
Hey Windows Group! This bug has been identified as a good "Windows candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
Similar ICE <details<summaryICE / Backtrace</summary<p</p</details
Prioritized this one as as per
This ICE went away between nightly-2020-06-28 and nightly-2020-06-29. Bisecting further now.
searched nightlies: from nightly-2020-06-28 to nightly-2020-06-29 regressed nightly: nightly-2020-06-29 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x86_64-pc-windows-msvc Reproduce with: </details
Minified, With the message,
's MCVE shows that this problem is not windows-specific. Updating labels accordingly.

Also, it looks to me like this MCVE still reproduces on the current nightly. (So something must have been off with my earlier bisection that claimed it was fixed. The original problem has been tricky for me to consistently reproduce.)
On the plus side, I was able to run cargo-bisect-rustc on 's MCVE (to identify the point where it regressed), and got this result: searched nightlies: from nightly-2020-06-22 to nightly-2020-07-14 regressed nightly: nightly-2020-06-26 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Culprit is likely ? cc
Keeping at P-critical based on conversation at: https://zulip-
reopening; the next beta was cut before this landed in master, so this ended up being a regression-from-stable-to-beta
however, I also think the bug is under control now that the PR has landed on nightly. Reprioritizing as P-high.
The fix was backported, closing.