During the discussion of my last RFC@eddybsuggested extending lint attributes with arbitrary parameters.
The base idea is that we may want to have a kind of configuration for some lints, embedded in the attribute. This would piggy-back on the existing attribute syntax.
There are actually two stages of expansions of this idea: In the first stage we still only allow one allow, warn or deny attribute per lint per item/module, in the second state we’d allow multiples, which would undoubtedly make the lint API more complex, but allow for things like #![warn(deprecation)] #![allow(deprecation(foo, bar))]. However this could also be written as #![warn(deprecation(ignore=foo, ignore=bar).
Motivation: We currently have a few lints which rely on whitelists that could be extended by configuration; also we have a few lints split into multiple lints so we can carve out niches for different cases that allow different levels. Those could be re-combined with configuration.
Seems like a useful idea in general. One thing I did with custom_derive! was to support parameters to derivation macros. The most immediately useful example is #[derive(From(T))] struct NewType(U);.
Aside: the meta grammar is also pretty restrictive. I don’t believe your second suggestion is syntactically valid at the moment; you can only “assign” a string, IIRC. If I was feeling evil, I’d also (separately) suggest that maybe the meta grammar could be extended to be equivalent to JSON…
It was already suggested to make allow arbitrary token trees in meta items, which brings them closer to macro syntax (I can’t be the only one who wants attr_rules!, right?)
@DanielKeep that’s not evil. And I wouldn’t use JSON, but token trees as @jschievink suggests. First, we already have them while parsing, plus some utility methods to work with them. Second, they’re more flexible than JSON.
The only catch being that various things in the compiler expect to be able to interpret meta items, which I assume is why they have such a limited grammar. JSON (or equivalent) is useful because it’s a pretty good balance of expressivity and simplicity.
TTs are definitely more flexible, but I imagine they’d be a pain to work with in the compiler.
In the interest of fairness, I should perhaps say that just yesterday I abused the fact that custom_derive! parses arguments as tts to do some really rather unpleasant things that would have been even worse had I been forced to use something like JSON.
So: tts are definitely more powerful. Then again, given the horrible things I’ve done, I maybe shouldn’t be listened to…
I’ve always assumed we would use token trees for this purpose, for what it’s worth (sorry I’m coming late to the discussion, just catching up on backlog).
