-
Notifications
You must be signed in to change notification settings - Fork 39
Can bypass #[repr(packed)] checking since rust 1.57 #342
Copy link
Copy link
Closed
Labels
C-bugCategory: related to a bug.Category: related to a bug.C-upstream-bugCategory: This is a bug of compiler or dependencies (the fix may require action in the upstream)Category: This is a bug of compiler or dependencies (the fix may require action in the upstream)I-unsoundA soundness hole (worst kind of bug), see: https://en.wikipedia.org/wiki/SoundnessA soundness hole (worst kind of bug), see: https://en.wikipedia.org/wiki/Soundness
Metadata
Metadata
Assignees
Labels
C-bugCategory: related to a bug.Category: related to a bug.C-upstream-bugCategory: This is a bug of compiler or dependencies (the fix may require action in the upstream)Category: This is a bug of compiler or dependencies (the fix may require action in the upstream)I-unsoundA soundness hole (worst kind of bug), see: https://en.wikipedia.org/wiki/SoundnessA soundness hole (worst kind of bug), see: https://en.wikipedia.org/wiki/Soundness
Since rust 1.57 it is possible to put proc macro attributes after derive (see rust-lang/rust#81119)
so given proc macro crate like that:
and following usage :
__PinProjectInternalDerive won't notice that at the end of the expansion there is #[repr(packed)] on struct
Of course,
--cap-lints=warnis still required to actually compile itI'm not sure how probable it is to trigger this problem in real code base..