Workweek compiler lints

Compiler Lints

https://github.com/kmcallister/rfcs/blob/lints/active/0000-loadable-lints.md

• kmc: brainstorming what lints we want for Servo. We thought of forbidding non-abstract units in modules that have been converted. if we get around to doing TLS, we'll want crypto lints to make sure we don't screw it up.
• jack: what are the lints we have for servo so far?
• kmc: #1 is jsmanaged, hopefully will be a reasonable testcase.
• jack: that's what, avoid returning js, jsref?
• kmc: you shouldn't be able to return jsref due to lifetimes. need to make sure that js only present in JS managed types with trace hooks.
• gw: in games, only allowed to allocate during init/deinit. could something like that be linted?
• jack: how in C? checked a global and asserted?
• gw: yes
• pcwalton: we have a lint for disabling allocation in given module
• kmc: you can put custom attributes on things and check them in lints.
• pcwalton: when you have HOF, harder.
• kmc: lints don't have to catch every error.
• gw: how does taking an AST work with formatting lints?
• kmc: currently can't check tabs vs. spaces, it's AST. pretty flexible, could add more methods to lint trait. could add method for checking string before tokenized, before token tree, before parse...
• gw: are comments present?
• kmc: not right now. someone's doing work to preserve original text in token tree, throwing out comments. we have attributes, so we mostly don't need to put lint metadata in comments (want https://github.com/rust-lang/rfcs/pull/16 though). in html parser, there are macros that expand to match statements. these look at internal ids assigned to interned strings, and consumer code shouldn't see that, but i can't make it private because macros could expand everywhere. a lint could help with this. macros don't scope cleanly, fixing that is a big project, but lints could help avoid problems. other things may be similar.
• jack: would be nice to get style guidelines as lints. is there warning in rust for missing docs for public items?
• kmc: yes. lints can also access the doc strings for spellcheck, formatting, etc.
• jack: plan to rewrite lints in new framework?
• kmc: rustc's lints are mostly in this framework now, as a module that's part of rustc. might later move them to an extern crate that's automatically injected like libstd. some passes in the backend aren't integrated yet, like enum sizing.
• kmc: Lints could also walk the code just before it's handed to LLVM, for cases that can't be done in earlier passes.
• kmc: rust-lua needs to ensure that any rust function calling lua function that might longjmp doesn't have objects on stack with destructors. This could be done as a lint.
• gw: in lint code, can you access platform, arch, cpu, etc?
• kmc: you can access compiler driver session. (https://github.com/mozilla/rust/blob/master/src/librustc/driver/session.rs ) targ_cfg field has all those things. -kmc: similar to lint plugins, we could also have "cfg plugins" that dynamically decide what to compile
• kmc: anything that doesn't cleanly fit in lint could be a new kind of plugin; adding these is easy. i did a huge refactor of rust's lint code but once that was done, actually adding lint plugins was like 200 lines.
• jack: are there other compilers that have this?
• kmc: java, gcc, llvm. gcc was slow to add it due to ideological concerns about code sharing. still fair amount of effort to add clang plugin.
• jack: it seems like rustc is simple enough that people will actually do this.
• kmc: there's a fine line, because we can't guarantee a stable API. people will be excited, but we should be explicit that if you write a lint then you may need to rewrite it tomorrow.
• jack: seems reasonable.
• kmc: totally fine for servo. but once we release 1.0 and people are not in early adopter mentality, could get grumpier about it. it's feature gated but we could make it clearer what that means
• kmc: since we use llvm, we could expose everything needed for llvm plugins and write them in rust.
• jack: when will this land?
• kmc: RFC for plugin registrar was approved, code is being reviewed. RFC for lints themselves hasn't seen much discussion. see what discussion happens in next meeting.
• gw: is there a way to see from a binary which lints were used? for example, crypto library would be good to guarantee it was built with certain set.
• kmc: good idea. could store string of lints and libraries in final binary, still don't know versions used. could library force certain lints? can't link it without required set of lints? some libraries will have safety guarantees that are enforced by lints, so we should support that. scary relying on lints for safety but the practical alternative is that people won't check those assumptions at all. [This is a tricky thing that the community will need to find a consensus norm about.]

(live demo based on https://gist.github.com/kmcallister/3409ece44ead6d280b8e)