repr attributes can be applied at module level

[gnzlbg]

Spot what's wrong with this code:

#![repr(C)] struct Foo(i32);

extern "C" {
    fn foo(x: Foo);
}

fn main() {}

(Playground)

For some reason, top-level #![repr(..)] attributes are allowed, so Foo isn't repr(C). Sadly,
@rust-lang/underhanded isn't a thing.

[gnzlbg]

cc @Centril ^^^ I don't know who is familiar with libsyntax or the library that handles this.

[jonas-schievink]

I don't think attributes that affect codegen are checked for validity at all. The same thing happens for #[cold], #[inline], etc.

[hanna-kruppe]

Some attributes including #[repr] and #[inline] are checked, it appears it's just not visiting the root module. Nested modules do get checked.

[Centril]

In case it turns out that many people rely on this, we could give reasonable (and arguably desirable) interpretation to #![inline] and #![repr(C)]: apply these recursively in the module to e.g. structs and fns (unless there is conflict, in which case the most-local attribute is chosen).

[gnzlbg]

If people rely on this compiling, but doing nothing, changing the repr of all types silently feels like a footgun.

[carbotaniuman]

I feel the standard warn by default, deny by default, hard error approach is the easiest way to handle this.

Maybe even skip to deny by default.

[varkor]

Given that occurrences of #![repr(C)] currently do nothing, and it's easy to search for in a codebase (and thus remove or audit), I don't see a strong reason not to start emitting errors, rather than just linting, on these, as long as we can determine this won't break downstream code if there's a crate making this mistake.

[varkor]

I don't think attributes that affect codegen are checked for validity at all. The same thing happens for #[cold], #[inline], etc.

We should fix this too, in the same manner as @rkruppe pointed out. (Either as part of this issue, or in a new issue.) Lack of validity checking can cause concrete problems, as in #64768.

[ehuss]

Closing, as this is now a hard error via #76329.