Pre-RFC: Parametric Lints

[llogiq]

During the discussion of my last RFC @eddyb suggested 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.

What do you folks think?

[DanielKeep]

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…

[jschievink]

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?)

[llogiq]

@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.

[DanielKeep]

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.

[llogiq]

Ok, let’s just say we’re gonna have some hierarchical structure (without defining whether that’s JSON, RON, YAML, S-Exprs or whatever).

[DanielKeep]

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…

[eddyb]

Pretty sure all possible JSON syntaxes form valid token trees, modulo lexing of string literals.

@jschievink I think decorator_rules! would rule ;).

[nikomatsakis]

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).

[llogiq]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.