I've noticed recently that there is a bunch of const trait related experimental features in Rust to allow calling trait methods in const context, like const_trait_impl, const_convert, const_ops, const_cmp, const_clone, const_default, const_iter. The #[derive_const(...)] attribute works like #[derive()] but generates const trait implementations.
However, when I want to extend third-party derive macros to generate const trait impls, for example the macros provided by derive_more, I don't know how to distinguish between whether a derive macro is passed in through #[derive(...)] or #[derive_const(...)], so the only way I can decide whether a derived trait impl should be const is to define a custom attribute #[const_impl(...)] to pass in the names of traits that I want to const impl. The details can be seen in my fork repo of derive_more. With testing I found that even if a third-party macro is passed in through #[derive_const(...)], it works exactly the same as passed in through #[derive(...)]
I found little helpful information when searching for the web about const trait derive macros. So is it currently possible to distinguish between derive macros passed in by #[derive(...)] and by #[derive_const(...)] in user-defined proc-macro libs?