Skip to content

ignored link and crate_type attributes #3348

Closed

Description

@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.

Activity

  1. jesse99 commented on Sep 2, 2012

    @jesse99
    ContributorAuthor

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

  2. brson commented on Sep 2, 2012

    @brson
    Contributor

    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.

  3. jesse99 commented on Sep 3, 2012

    @jesse99
    ContributorAuthor

    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.

  4. msullivan commented on Jul 1, 2013

    @msullivan
    Contributor

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

  5. klutzy commented on Sep 30, 2013

    @klutzy
    Contributor

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

  6. added a commit that references this issue on Nov 26, 2013
    c6a87c2
  7. added a commit that references this issue on Mar 9, 2024
  8. added a commit that references this issue on Aug 21, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-attributesArea: Attributes (`#[…]`, `#![…]`)

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions