rustc_hir_typeck/
opaque_types.rs

1use super::FnCtxt;
2impl<'tcx> FnCtxt<'_, 'tcx> {
3    /// We may in theory add further uses of an opaque after cloning the opaque
4    /// types storage during writeback when computing the defining uses.
5    ///
6    /// Silently ignoring them is dangerous and could result in ICE or even in
7    /// unsoundness, so we make sure we catch such cases here. There's currently
8    /// no known code where this actually happens, even with the new solver which
9    /// does normalize types in writeback after cloning the opaque type storage.
10    ///
11    /// FIXME(@lcnr): I believe this should be possible in theory and would like
12    /// an actual test here. After playing around with this for an hour, I wasn't
13    /// able to do anything which didn't already try to normalize the opaque before
14    /// then, either allowing compilation to succeed or causing an ambiguity error.
15    pub(super) fn detect_opaque_types_added_during_writeback(&self) {
16        let num_entries = self.checked_opaque_types_storage_entries.take().unwrap();
17        for (key, hidden_type) in
18            self.inner.borrow_mut().opaque_types().opaque_types_added_since(num_entries)
19        {
20            let opaque_type_string = self.tcx.def_path_str(key.def_id);
21            let msg = format!("unexpected cyclic definition of `{opaque_type_string}`");
22            self.dcx().span_delayed_bug(hidden_type.span, msg);
23        }
24        let _ = self.take_opaque_types();
25    }
26}
rustc_hir_typeck/opaque_types.rs

rustc_hir_typeck/
opaque_types.rs
