Looks like I'm finally working towards an effective solution for https://github.com/rust-analyzer/rust-analyzer/issues/3188:
16069ms - crate_def_map_query @ salsa 13ms - crate_def_map:wait (24610 calls) 4816ms - item_tree_query (8202 calls) 10773ms - macro_expand (8201 calls) 0ms - rewrite (1 calls) 465ms - ???
I'm not sure why this is so slow now, I might have accidentally implemented procedural attribute macros
[ERROR hir_def::nameres::collector] name resolution is stuck
Clearly something broke :)
Heh, new features which regress performance considerably are my favorite!
First you an tweet about new feature, and next week you can tween about perfomrnace improving 2x!
thread '<unknown>' has overflowed its stack fatal runtime error: stack overflow
huh, looks like the overflow guards in name resolution are not enough
38480ms - crate_def_map_query @ hir_def 15767ms - crate_def_map:wait 124ms - DefCollector::resolve_macros @ 21 macros, 748 attrs 0ms - crate_def_map:wait (1517 calls) 33ms - item_tree_query (766 calls) 73ms - macro_expand (766 calls) 0ms - rewrite (2 calls) 18502ms - DefCollector::resolve_macros (8191 calls)
odd profiler output, it's only including the
yes, apparently, for some crate, we're now expanding 748 attribute macros
Practically all it does is crash the proc macro server, looks like we'll have to come up with a more stable solution for that before this work properly...
@Jonas Schievink reminder that this is a thing: https://github.com/matklad/backtrace-on-stack-overflow
oh well this explains the "name resolution is stuck" error, salsa runs right into the iteration limit
15699ms - crate_def_map_query @ salsa 15695ms - DefCollector::resolve_macros (8192 calls)