You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Slow coherence checking and type checking. #138828
I was working on creating a crate and encountered some unexpectedly long compile times.
I don't have a minimal reproduction, but I have expanded my macros, and copied the code into a playground.
It occurs on all channels. It is still pretty bad even with the parallel front-end enabled. According to time-passes, the biggest culprits were coherence checking and type checking.
My use case is clearly atypical, so I will understand if you consider this frivolous and close it. (Although, when I searched to see if my issue had already been reported, I did notice submitted situations that were arguably even less likely to be encountered by anyone.)
********************************************************************************
Regression in nightly-2024-01-18
********************************************************************************
converted 2024-01-17 to 098d4fd74c078b12bfc2e9438a2a04bc18b393bc
converted 2024-01-18 to 6ae4cfbbb080cafea7f6be48ce47678ee057352c
get_commits_between returning commits, len: 9
commit[0] 2024-01-16: Auto merge of #119977 - Mark-Simulacrum:defid-cache, r=cjgillot
commit[1] 2024-01-17: Auto merge of #120036 - weihanglo:update-cargo, r=weihanglo
commit[2] 2024-01-17: Auto merge of #120019 - lcnr:fn-wf, r=BoxyUwU
commit[3] 2024-01-17: Auto merge of #119651 - novafacing:proc_macro_c_str_literals, r=Amanieu
commit[4] 2024-01-17: Auto merge of #119922 - nnethercote:fix-Diag-code-is_lint, r=oli-obk
commit[5] 2024-01-17: Auto merge of #119111 - michaelwoerister:measureme-11, r=Mark-Simulacrum
commit[6] 2024-01-17: Auto merge of #119670 - cjgillot:gvn-arithmetic, r=oli-obk
commit[7] 2024-01-17: Auto merge of #119930 - Urgau:check-cfg-empty-values-means-empty, r=petrochenkov
commit[8] 2024-01-17: Auto merge of #118708 - davidtwco:target-tier-assembly-test, r=Mark-Simulacrum
use core::{marker::PhantomData, ops::Deref};structDerefOnly<T: ?Sized>(PhantomData<T>);impl<T:Deref>DerefforDerefOnly<T>{typeTarget = DerefOnly<T::Target>;fnderef(&self) -> &Self::Target{&DerefOnly(PhantomData)}}structEmpty;implDerefOnly<Empty>{fnwhatever(&self){}}// copy-paste the function a couple of times if your pc is too fast to noticefnfoo_1(){DerefOnly(PhantomData::<&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&Empty,>).whatever();}fnfoo_2(){DerefOnly(PhantomData::<&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&Empty,>).whatever();}fnmain(){}
What's happening is we create a let x = DerefOnly{0: PhantomData<&&..&&Empty>}, and try to call a method .whatever() on it. The type we have at hand doesn't have said method but the type x.deref().deref()......deref() does. And it's this deref chain that's taking us some time to traverse. I think... I'm by no means an expert.
Activity
moxian commentedon Mar 22, 2025
Bisection: While this code has always been slow, it took an extra ~30% comptime hit in nightly-2024-02-15.
Unfortunately that nightly has several type-level PRs landing, making it hard to pinpoint regression precisely, but #118882 sounds most likely
cargo-bisect-rustc output
Regression in nightly-2024-02-15
converted 2024-02-14 to a84bb95
converted 2024-02-15 to ee9c7c9
get_commits_between returning commits, len: 9
for_each_item_bound#120942 - compiler-errors:deep-assoc-hang, r=lcnrcargo update#120454 - clubby789:cargo-update, r=NilstriebEdit: and also another ~20% hit several weeks prior in
nightly-2024-01-18. Likely #120019cargo-bisect-rustc out
@rustbot label: +T-compiler +T-types +A-coherence +I-compiletime -needs-triage +A-trait-system
moxian commentedon Mar 23, 2025
Smaller:
What's happening is we create a
let x = DerefOnly{0: PhantomData<&&..&&Empty>}, and try to call a method.whatever()on it. The type we have at hand doesn't have said method but the typex.deref().deref()......deref()does. And it's this deref chain that's taking us some time to traverse. I think... I'm by no means an expert.diondokter commentedon Jul 29, 2025