I think there are only two cases:
-
You have a fixed set of features that MyLibraryCrate advertises for other crates that depend on MyLibraryCrate to enable or disable. If you know all the features ahead of time, you can use the hand-specified cfg checker macro chain I listed above.
-
The user specifies #[cfg(...)] attributes as part of their input that you're parsing into tokens for a given macro, and the macro needs to be able to evaluate the state of the predicates in the #[cfg(...)] attribute as it parses. This is the use case that I had to solve and I go into more detail on that here: Supporting or evaluating #[cfg(...)] in proc macro parameters? - #2 by recatek -- the summarized version is that you parse the input twice: in the first pass you find all the #[cfg(...)] attributes and build a unique ordered set of their predicates. Then you generate the cfg checker macro chain I described above from that predicate set, and have the chain terminate in a call to your second "real" proc macro that takes in the cfg predicate states, and the data, and actually generates your output.
The two-parse thing isn't ideal but in cases like this where the alternative would be a combinatorial explosion of output code I think it's preferable. That said, in my case I explicitly couldn't do the T=() option since it would have had a runtime cost, so if you can then that's probably preferable.