Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

#![inline(never)] vs #[inline(never)] #69365

Closed
BartMassey opened this issue Feb 22, 2020 · 5 comments
Closed

#![inline(never)] vs #[inline(never)] #69365

BartMassey opened this issue Feb 22, 2020 · 5 comments
Labels
A-attributes Area: Attributes (`#[…]`, `#![…]`) C-bug Category: This is a bug.

Comments

@BartMassey
Copy link
Contributor

BartMassey commented Feb 22, 2020

Consider this code:

#![inline(never)]

pub fn f(x: u64) -> u64 {
    x + 1
}

pub fn g(x: u64) -> u64 {
    f(x) + 1
}

and the resulting assembly:

playground::f:
	leaq	1(%rdi), %rax
	retq

playground::g:
	leaq	2(%rdi), %rax
	retq

I know I was hoping for a lot there, and I know that #[inline(never)] is just a suggestion. That said, given that I didn't get a warning here I would have expected removing the ! to produce the same output. But

#[inline(never)]
pub fn f(x: u64) -> u64 {
    x + 1
}

pub fn g(x: u64) -> u64 {
    f(x) + 1
}

yields

playground::f:
	leaq	1(%rdi), %rax
	retq

playground::g:
	pushq	%rax
	callq	*playground::f@GOTPCREL(%rip)
	addq	$1, %rax
	popq	%rcx
	retq

If #![inline(never)] is supposed to work, it would be nice to have it work here. If it is not, it would be nice to get a warning lint.

(It would also be nice if inline(never) was a requirement, not just a suggestion. But that's a separate issue, I think.)

Meta

Built on the playground in release mode. Same behavior with rustc stable 1.41.0 and 1.43.0-nightly (2020-02-20 2c462a2f776b899d4674)

@BartMassey BartMassey added the C-bug Category: This is a bug. label Feb 22, 2020
@ehuss
Copy link
Contributor

ehuss commented Feb 23, 2020

Many built-in attributes are not validated that they appear in correct locations, particularly for the codegen attributes. I don't think there is a single issue tracking this, but I think #55112 is probably the closest?

There are a number of other issues reporting similar confusion about attributes being ignored: #54044, #47725, #54584, #53901, #64734, #65128. The lint control attributes (allow/warn/deny) are particularly gnarly since they can go anywhere, but don't always do what people expect (#61552, #59144 among others).

@hanna-kruppe
Copy link
Contributor

#64734 is especially relevant because, as discussion there immediately identified, #[inline] is in the same boat as #[repr]: we already have a pretty comprehensive lint for these specific attributes being misapplied, it only forgets to check attribute of the root module specifically. As @varkor already said in that thread, we should really fix that.

@BartMassey
Copy link
Contributor Author

Thanks for the insights!

It would occasionally be convenient to be able to say "inline nothing in this module", if that was easy to provide. I wrote #![inline(never)] on purpose in some code we were trying to debug / analyze.

@hanna-kruppe
Copy link
Contributor

hanna-kruppe commented Feb 26, 2020

Such a feature might not be hard to provide, but we need fix the bug in attribute checking anyway (since it affects other attributes too), and IMO we should do that first. I'd like at least one release where rustc highlights potential pre-existing typos such as

///! This is a simple crate with a few functions, one of which is `#[inline]`.
#![some_crate_attribute]

#![inline] // typo: a ! snuck in
fn foo() {
    // ...
}

// ... other functions, which aren't intended to be #[inline]

@ehuss ehuss added the A-attributes Area: Attributes (`#[…]`, `#![…]`) label Sep 15, 2020
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this issue Oct 5, 2020
…l, r=matthewjasper

Add check for doc alias attribute at crate level

Fixes rust-lang#76298, rust-lang#64734, rust-lang#69365.

r? @ollie27
@ehuss
Copy link
Contributor

ehuss commented Jan 25, 2021

Closing since #![inline] now results in an error (or warning in some cases) when used in the wrong position (via #73461 and #76329), and #80641/#80920 are plugging up the last few holes.

@ehuss ehuss closed this as completed Jan 25, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-attributes Area: Attributes (`#[…]`, `#![…]`) C-bug Category: This is a bug.
Projects
None yet
Development

No branches or pull requests

3 participants