-
Notifications
You must be signed in to change notification settings - Fork 13k
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
warn less about non-exhaustive in ffi #116863
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,51 @@ | ||
use std::ops::ControlFlow; | ||
|
||
use rustc_errors::DiagMessage; | ||
use rustc_hir::def::CtorKind; | ||
use rustc_middle::ty; | ||
|
||
use crate::fluent_generated as fluent; | ||
|
||
/// Check a variant of a non-exhaustive enum for improper ctypes | ||
/// | ||
/// We treat `#[non_exhaustive] enum` as "ensure that code will compile if new variants are added". | ||
/// This includes linting, on a best-effort basis. There are valid additions that are unlikely. | ||
/// | ||
/// Adding a data-carrying variant to an existing C-like enum that is passed to C is "unlikely", | ||
/// so we don't need the lint to account for it. | ||
/// e.g. going from enum Foo { A, B, C } to enum Foo { A, B, C, D(u32) }. | ||
pub(crate) fn check_non_exhaustive_variant( | ||
non_local_def: bool, | ||
variant: &ty::VariantDef, | ||
) -> ControlFlow<DiagMessage, ()> { | ||
// non_exhaustive suggests it is possible that someone might break ABI | ||
// see: https://github.com/rust-lang/rust/issues/44109#issuecomment-537583344 | ||
// so warn on complex enums being used outside their crate | ||
if non_local_def { | ||
// which is why we only warn about really_tagged_union reprs from https://rust.tf/rfc2195 | ||
// with an enum like `#[repr(u8)] enum Enum { A(DataA), B(DataB), }` | ||
// but exempt enums with unit ctors like C's (e.g. from rust-bindgen) | ||
if variant_has_complex_ctor(variant) { | ||
return ControlFlow::Break(fluent::lint_improper_ctypes_non_exhaustive); | ||
} | ||
} | ||
|
||
let non_exhaustive_variant_fields = variant.is_field_list_non_exhaustive(); | ||
if non_exhaustive_variant_fields && !variant.def_id.is_local() { | ||
return ControlFlow::Break(fluent::lint_improper_ctypes_non_exhaustive_variant); | ||
} | ||
|
||
ControlFlow::Continue(()) | ||
} | ||
|
||
fn variant_has_complex_ctor(variant: &ty::VariantDef) -> bool { | ||
// CtorKind::Const means a "unit" ctor | ||
!matches!(variant.ctor_kind(), Some(CtorKind::Const)) | ||
} | ||
|
||
// non_exhaustive suggests it is possible that someone might break ABI | ||
// see: https://github.com/rust-lang/rust/issues/44109#issuecomment-537583344 | ||
// so warn on complex enums being used outside their crate | ||
pub(crate) fn non_local_and_non_exhaustive(def: ty::AdtDef<'_>) -> bool { | ||
def.is_variant_list_non_exhaustive() && !def.did().is_local() | ||
} |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -27,3 +27,14 @@ pub enum NonExhaustiveVariants { | |
#[non_exhaustive] Tuple(u32), | ||
#[non_exhaustive] Struct { field: u32 } | ||
} | ||
|
||
// Note the absence of repr(C): it's not necessary, and recent C code can now use repr hints too. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The docs don't make explicit that the ABI matches C's - https://doc.rust-lang.org/reference/type-layout.html#primitive-representation-of-field-less-enums - my sense is that's probably just an oversight? But as-is it's not clear to me that this is accurate. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. typedef enum Name: uint8_t {
/* fields */
} Name; is legal C code as-of C23 and must, by brute force of logic, match #[repr(u8)]
enum Name {
/* fields */
} or fail to compile, according to my understanding. (There simply isn't any other valid representation for the two types in either language's rules, if the Rust variants are data-free: they must match.) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I am happy to revise the wording but
|
||
#[repr(u32)] | ||
#[non_exhaustive] | ||
petrochenkov marked this conversation as resolved.
Show resolved
Hide resolved
|
||
pub enum NonExhaustiveCLikeEnum { | ||
One = 1, | ||
Two = 2, | ||
Three = 3, | ||
Four = 4, | ||
Five = 5, | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do you think it would make sense to move the entire lint over to this module?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, yes, but I wanted to take it in phases to keep this diff comparatively contained.