Pluggable lints (and attributes)

[lilyball]

Just as we now support pluggable macros, I would love to see pluggable lints (with associated pluggable attributes). I'm thinking these lints/attributes could be scoped by the crate name, so something like

#[attribute_registrar]
pub fn attribute_registrar(registrar: |Name, Type|) {
    // register attribute names with whatever info is used
    // to determine if and how arguments are specified
    register(token::intern("myattr"), ...);
}

#[lint_registrar]
pub fn lint_registrar(register: |Name, LintExtension|) {
    register(token::intern("mylint"), ...);
}

when loaded as

#[feature(phase)];
#[phase(syntax)]
extern mod foo;

would add the attribute #[foo::myattr] and the lint foo::mylint.

The motivating reason here for me is that I believe for my rust-lua project to be safe I need to have a lint to ensure that the functions exposed to Lua do not make any Lua calls when there is a value with a destructor on the stack. To that end I want to annotate my Lua methods with #[lua::longjmp] and have a lint that disallows calling any #[lua::longjmp] method with destructors on the stack.

[huonw]

associated pluggable attributes

This is kinda-meaningless, since attributes are already arbitrary, and having truly "pluggable attributes" would essentially require being able to modify any part of the compilation process (since attributes can be read anywhere). Unless you just mean adding attribute to the list of known attributes for the attribute_usage lint.

👍 to pluggable lints though.

[lilyball]

Yes, I basically just mean adding an attribute to the list of known attributes for attribute_usage. Also, I wanted to scope the attribute so that way two pluggable lints don't accidentally conflict.

[ghost]

This is now done, I think?

[steveklabnik]

Yes: #14067