ignored link and crate_type attributes

[jesse99]

The project below fails to build using rustc -o bin/logging2 crate.rc with error main function not found. If rustc -o bin/logging2 --lib crate.rc is used it complains about missing crate link meta 'name', using 'logging2' as default and missing crate link meta 'vers', using '0.0' as default.

Makefile:

RUSTC ?= rustc

dummy1 := $(shell mkdir bin 2> /dev/null)

all:
    $(RUSTC) -o bin/logging2 crate.rc
    #$(RUSTC) -o bin/logging2 --lib crate.rc

check:
    $(RUSTC) -o bin/test-logging2 --test crate.rc
    export RUST_LOG=test-logging2::logging2=3 && ./bin/test-logging2

clean:
    rm -rf bin

crate.rc:

use std;

#[link(name = "logging2",
       vers = "0.1",
       uuid = "91E62841-B9F3-4721-97C6-621BEEE2DA1B")]

#[crate_type = "lib"]

mod logging2;

logging2.rs:

#[test]
fn test_logging()
{
    error!("error level");
    warn!("warn level");
    info!("info level");
}

This is with a rust from master on Sep 1, 2012.

[jesse99]

Stuff like #[warn(deprecated_pattern)] is also being ignored. Was able to get those, at least, working using the -W rust command-line switch.

[brson]

This is likely because of the placement of the crate attributes. As written they are actually being applied to the logging2 mod.

This way they will apply to the crate:

// attributes with a trailing semi-colon apply to the 'containing item', in this case the crate. These are considered 'inner attributes'
#[link(name = "logging2",
       vers = "0.1",
       uuid = "91E62841-B9F3-4721-97C6-621BEEE2DA1B")]; // <- indicates an inner attribute

#[crate_type = "lib"];

// inner attributes must come before the items contents, e.g. use statements.
use std;

mod logging2;

I know this is really unintuitive behavior. There's some discussion in #2569.

[jesse99]

Good call. The original code had use std; as the very first thing which lead to expected outer comment errors. Adding an outer comment (//! or /*! */ I think) did not get rid of the error and in my flailing around I wound up getting rid of a compiler error by removing the semi-colons.

It is unintuitive which might be OK if the error messages were clear enough to allow users to figure out the problem and the solution, but that is far from the case.

[msullivan]

So, is this actually a bug? Or is it just a consequence of #2569?

[klutzy]

I think misplaced crate_mod and link should be error regardless of syntax we will use.