So this already answers the what function chain is equivalent question
From there, if you happen to feed code to quote! that could not be syn::parsed as the target type, parse_quote…! then panics.
You also seem to be using the proc-macro-error (quite heavyweight)error reporting framework. Such framework works by wrapping the proc-macro entry-point calls inside catch_unwind! scopes (to catch panics, à la C++ exceptions), and using helper thread-local storage adjacent to the catch_unwind scoping.
Thus, if your abort_call_site!() happens in a function that was not transitively called by a #[proc-macro-error]-annotated proc-macro, or if it happened from within a helper thread, then the companion thread-local storage won't be in the expected "scoped" state, hence yielding that error.
I have very mixed feelings about the idea behind that crate (which is nonetheless a well-written crate): it involves mixing the proc-macro framework from cargo/rust with its own error-reporting framework, and the whole thing is achieved through global state, panic-catching, and worse: helper procedural macros. If proc-macros have already a rather steep compile-time cost, nesting them, dependency-wise, just aggravates the issue. I don't see it being worth it when syn::Error::new_spanned(…).to_compile_error() yields already 95% good error messages. Embedding a slow-to-compile cognitive-burden-to-learn and with-implementation-restrictions framework for that 5%-improvement for the error messages is so not worth it, in my opinion. ↩︎
Thanks for the detailed insights. I take your point about proc-macro-error, and I think I'll try to move away from that - I have a peculiar error that only shows up in a third party crate - all unit and integration tests in the proc-macro crate are green, so I'm beginning to think outside the box and this is one observation I'll take on board.