Allow certain lints in .fixed compile test

[xFrednet]

Compiletest currently automatically allows all unused lints in the CompileFail and Ui modes. However, this doesn't extend to .fixed files, which are used inside Clippy. For this reason, we still have a bunch of #[allow()] attributes. To avoid this, it would be nice to have an option to allow lints inside .fixed compilation tests.

In a related discussion, we agreed that it would also be cool, if we could be more specific than just allowing all lint's inside the unused group. I would suggest adding a new configuration with an enum like this:

pub enum LintConfiguration {
    /// No lints are automatically allowed
    None,
    /// All lints inside the `unused` lint group are allowed
    UnusedLints,
    /// List of lints that should be allowed. The names should be
    /// provided in the console format using dashes
    SpecificLints(&[&str])
}

I would be happy to work on this. Any feedback regarding the implementation are also welcome!

Should I work on the upstream version or in this repo? 🙃

Inspired by rust-lang/rust-clippy#7611.

[Manishearth]

I think it would be ideal if this could be worked on in both versions

(or if you could update this to have the same code as upstream)

frustratingly, the rustc folks are not super interested in making their version available out of tree.

[xFrednet]

I'm happy to implement it in both. It's probably good to create an issue in Rust first to get some early feedback. Is there someone you recommend cc'ing in that issue?

(or if you could update this to have the same code as upstream)

frustratingly, the rustc folks are not super interested in making their version available out of tree.

I also wanted to read up on the reasoning behind not moving it out. This was discussed in rust-lang/rust#82946 to my knowledge. Either way, if working on this is fun, I'll probably look into syncing this with the rustc version. And maybe look at some other issues 🙃

[Manishearth]

Is there someone you recommend cc'ing in that issue?

Unsure.

Either way, if working on this is fun, I'll probably look into syncing this with the rustc version. And maybe look at some other issues

That would be really great! I don't have time to do much more than just merges here.

Perhaps we can use git subtree or something to keep things synced (this repo can stay fossilized as a working out-of-tree option)