Re-enable detection of unused library #![feature] directives

[alexcrichton]

Currently the compiler will warn users about unused #![feature] directives if they're (a) a library feature and (b) not actually ever used. The compiler doesn't currently warn you about unused #![feature] directives tied to language features.

In the process of making the stability annotations more incremental-friendly (#44137) this check in the compiler has proven to be very difficult to make incremental. Namely what's happening here is:

• There's a function, check_stability, which is used to verify that an API can actually be used.
• In this function if the API in question is unstable and the feature is activated, then this feature name is stored off in a side table.
• As we run through the compiler this side table gets bigger and bigger. Right now this table is mostly built up during typeck. (I don't know the precise reason as to why it's in typeck, personally)
• Finally near the end of compilation we go through this table and use it to warn about unused #![feature] directives.

This "put things in a table on the side" behavior isn't very incremental friently and isn't too easy to transition over to the query system. For now this specific warning seems like it probably isn't that important at Rust 1.20.0 (while it was probably very important at Rust 1.0.0). I'm going to comment this out for now so we're not going to get lints/warnings about unused library features.

This is a FIXME to track re-enabling this warning!

[alexcrichton]

Note that this also applies to the lint of "this #[feature] isn't needed because it's stable", that gets emitted at most once but it's not clear how to do that any more.

[durka]

Oh, so the "unused feature" lint is going to be disabled entirely? That could potentially unblock me over at #43017 (comment) as I currently can't figure out how to correctly populate the side table you're talking about.

[SimonSapin]

Maybe side tables are fundamentally incompatible with incremental and the set of used features (perhaps optimized as a bit map) should be part of the “result” of relevant compiler queries?