#![cfg_attr] doesn't work for crate-level attributes

[lilyball]

The #[cfg_attr] attribute doesn't work correctly for crate-level attributes. It seems to work in other cases as an inner attribute, but for crate-level attributes it yields the same warning that you'd see if you used the crate attribute on a non-root module:

#![cfg_attr(foo, crate_type="lib")]

fn main() {}

When compiled with rustc --cfg foo:

unnamed.rs:1:18: 1:35 warning: unused attribute, #[warn(unused_attributes)] on by default
unnamed.rs:1 #![cfg_attr(foo, crate_type="lib")]
                              ^~~~~~~~~~~~~~~~~
unnamed.rs:1:18: 1:35 warning: crate-level attribute should be in the root module, #[warn(unused_attributes)] on by default
unnamed.rs:1 #![cfg_attr(foo, crate_type="lib")]
                              ^~~~~~~~~~~~~~~~~

[lilyball]

I'm actually kind of surprised to see this bug. I would have expected #![cfg_attr] to be used in order to enable features based on cargo features, e.g. a cargo feature nightly that enables the use of features such that the same lib can be used in the beta and nightly channels.

[lilyball]

Also to note, the --pretty expanded output yields a valid crate-level attribute that works properly when compiled.

[klutzy]

It's a bug/limitation that some special attributes doesn't work with cfg_attr. For example, cfg_attr doesn't work with #[path] attribute. In the other hand, #![cfg_attr(foo, allow(dead_code))] works.
This is caused because crate_type or path attributes are consumed before cfg_attr expansion.

[sfackler]

It may make sense to move #[cfg_attr] and #[cfg] processing directly into the parser.

[lilyball]

@klutzy It looks like the problem is it collects some crate information prior to running the first strip_unconfigured_items pass. Is there some reason it doesn't simply run that pass as the very first thing?