Skip to content

#[link_name] is ignored on extern blocks #47725

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
cuviper opened this issue Jan 24, 2018 · 4 comments · Fixed by #73461
Closed

#[link_name] is ignored on extern blocks #47725

cuviper opened this issue Jan 24, 2018 · 4 comments · Fixed by #73461
Labels
A-attributes Area: Attributes (`#[…]`, `#![…]`) A-FFI Area: Foreign function interface (FFI) C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@cuviper
Copy link
Member

cuviper commented Jan 24, 2018

fn main() {
    println!("{}", unsafe { foo() });
}

#[link_name = "foobar"]
extern "C" {
    fn foo() -> u32;
}

This fails to link with undefined reference to `foo', but it didn't even try to find any foobar library.

With #[link(name = "foobar")], the error is the expected ld: cannot find -lfoobar.

There are a few places in libstd using #[link_name = "m"] extern {...}, so I wonder if those actually have any effect either.

@cuviper cuviper added A-attributes Area: Attributes (`#[…]`, `#![…]`) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. C-bug Category: This is a bug. labels Jan 24, 2018
@hanna-kruppe
Copy link
Contributor

AFAIK link_name is for individual extern items (example) and bears no relation to #[link(name=...)]. So this is "just" another case of not warning/erroring when an attribute is used in a position where it doesn't mean anything?

The fact that libstd got this wrong in some places is concerning, though 😅

@nagisa
Copy link
Member

nagisa commented Jan 25, 2018

Surprised again that the unused attribute lint is not firing.

@cuviper
Copy link
Member Author

cuviper commented Jan 25, 2018

Yeah, I think you're right that #[link_name] is simply not intended for this, so getting the lint to fire sounds like the right solution.

@alexcrichton
Copy link
Member

This may have been the ancient method of what #[link(name = "..")] is today, any usage in the standard library should be subsubed by the build.rs script I believe.

GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this issue Jan 4, 2020
…an-DPC

Remove unused `#[link_name = "m"]` attributes

These were perhaps supposed to be `#[link(name = "m")]` but linking libm should be handled by the libc crate anyway.

They should have triggered a compile error: rust-lang#47725
@jonas-schievink jonas-schievink added the A-FFI Area: Foreign function interface (FFI) label Apr 20, 2020
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this issue Sep 7, 2020
…acement, r=matthewjasper

Validate built-in attribute placement

Closes rust-lang#54584, closes rust-lang#47725, closes rust-lang#54044.

I've changed silently ignoring some incorrectly placed attributes to errors.  I'm not sure what the policy is since this can theoretically break code (should they be warnings instead? does it warrant a crater run?).
@bors bors closed this as completed in dbb73f8 Sep 12, 2020
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
A-attributes Area: Attributes (`#[…]`, `#![…]`) A-FFI Area: Foreign function interface (FFI) C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants