turn aligned-in-packed error into lint

[RalfJung]

Fixes #80926:
The aligned-in-packed check ignores the fact that generics exist, so it can trivially be bypassed. Acknowledge that by downgrading the hard error to a lint. The lint also only fires for repr(C) types, because that's the only case where that is a problem: the type may not actually match what the C compiler for the target does, if that C compiler is MSVC. This is tied up with rust-lang/rfcs#3845 and the general tension around repr(C) as a repr for predictable stable layout vs C compatibility. The error doesn't really help to make fixing the mess any easier though, so let's de-fang it.

Also fixes rust-lang/rfcs#3060; see that issue for a usecase that's made unnecessarily hard by the status quo.

Three years ago, the t-lang vibes seem to have been "yes let's downgrade this to a lint, that's kind of what it already is anyway".

Questions for t-lang:

• Are you still on-board with this?
• How should the lint be called? I went with aligned_fields_in_packed.
• When exactly should it fire? I currently require the outer packed type, the inner aligned type, and all the types in between to be repr(C). For Rust types I see no reason at all to forbid this combination, we can just define whatever we want for the layout there and IMO the current behavior makes a lot of sense.
• What should the default lint level be? I went with "deny" since it was a hard error after all.

Cc @rust-lang/opsem

[rustbot]

r? @mu001999

rustbot has assigned @mu001999.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler
• compiler expanded to 75 candidates
• Random selection from 21 candidates

[traviscross]

Makes sense to me. I propose to adopt your recommended answers to the questions you raised. Thanks @RalfJung.

@rfcbot fcp merge lang

[rust-rfcbot]

@traviscross has proposed to merge this. The next step is review by the rest of the tagged team members:

• @joshtriplett
• @nikomatsakis
• @scottmcm
• @tmandry
• @traviscross

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

[nikomatsakis]

@rfcbot reviewed

[rust-rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[tmandry]

@rfcbot reviewed

I had to think about it, but I agree with not linting on #[repr(Rust)] types. Scott brought up the great point that including a u32 in your type also modifies the alignment and we won't lint in that case. Also, if you're relying on the alignment in your unsafe code you should really start from a reference, and you can't get that from a field in a #[repr(packed)] struct.

For deny-by-default, it's a reasonable choice since this misbehaves on a Tier 1 platform.

[scottmcm]

Given that if it's generic or if you get the alignment via, say, [u16; 0] instead of align(2) then we wouldn't lint about it, I agree that treating this like "this is of course what it should do but MSVC is weird" sounds good.

@rfcbot reviewed