lint ImproperCTypes: refactor linting architecture (part 2)#146273
lint ImproperCTypes: refactor linting architecture (part 2)#146273niacdoial wants to merge 1 commit intorust-lang:mainfrom
Conversation
There was a problem hiding this comment.
I think a lot of this makes sense, but aren't there behavior changes here? It looks like tuples and arrays may be treated slightly differently.
Which is probably fine, that would ideally just be split from the refactoring and come with test updates.
1dbb0e2 to
f54061c
Compare
I moved the actual change in behaviour in a later commit. |
This comment has been minimized.
This comment has been minimized.
f54061c to
66037fd
Compare
This comment has been minimized.
This comment has been minimized.
66037fd to
2781ebd
Compare
"split type visiting into subfunctions" still has some changes right? (Possible I'm missing something here) |
That's a bit of logic that was moved from |
efe195a to
69b0807
Compare
This comment has been minimized.
This comment has been minimized.
69b0807 to
64106e6
Compare
|
Btw if these are ready for a more final review, feel free to un-draft them (just gets them actually into my queue) |
64106e6 to
359cb79
Compare
|
just double-checked: |
|
@niacdoial what exactly are these waiting on? I assume they're close to ready based on your above comment, but they are still marked as drafts. |
|
ah, I knew I was missing something (talking about the PR still being a draft) |
|
@rustbot reroll |
|
Sorry to play hot potato, but this seems like the most realistic outcome: |
|
Ok, then we return to
@rustbot author |
|
Reminder, once the PR becomes ready for a review, use |
c52aa53 to
2150411
Compare
….2, r=petrochenkov Improperctypes refactor2.2 This is "part 2/3 of 2/3 of 1/2" of the original pull request rust-lang#134697 (refactor plus overhaul of the ImproperCTypes family of lints) (all pulls of this series of pulls are supersets of the previous pulls.) previous pull: rust-lang#155358 next pull: rust-lang#146273 This commit splits the lint's `visit_type` function into multiple functions that focus on specific things: - visit_indirection (references, boxes, raw pointers) - visit_variant_fields (the list of fields of a struct, enum variant, or union) - visit_enum - visit_struct_or_union - visit_type (most "easy" decisions such as labeling `char` unsafe are here) since, during these visits, we often move from an "outer type" to an "inner type" (structs, arrays, pointers, etc...), two structs have been added to track the current state of a visit: - VisitorState tracks the state related to the "original type" being checked (function argument/return, static variable) - OuterTyData tracks the data related to the type "immediately outer to the current visited type" r? petrochenkov (because you asked me to)
Rollup merge of #155359 - niacdoial:improperctypes-refactor2.2, r=petrochenkov Improperctypes refactor2.2 This is "part 2/3 of 2/3 of 1/2" of the original pull request #134697 (refactor plus overhaul of the ImproperCTypes family of lints) (all pulls of this series of pulls are supersets of the previous pulls.) previous pull: #155358 next pull: #146273 This commit splits the lint's `visit_type` function into multiple functions that focus on specific things: - visit_indirection (references, boxes, raw pointers) - visit_variant_fields (the list of fields of a struct, enum variant, or union) - visit_enum - visit_struct_or_union - visit_type (most "easy" decisions such as labeling `char` unsafe are here) since, during these visits, we often move from an "outer type" to an "inner type" (structs, arrays, pointers, etc...), two structs have been added to track the current state of a visit: - VisitorState tracks the state related to the "original type" being checked (function argument/return, static variable) - OuterTyData tracks the data related to the type "immediately outer to the current visited type" r? petrochenkov (because you asked me to)
This comment has been minimized.
This comment has been minimized.
2150411 to
ac62a57
Compare
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
|
@rustbot review |
| | ty::Tuple(..) | ||
| | ty::Array(..) | ||
| | ty::Slice(_) => Self::UnusedVariant, | ||
| k @ _ => bug!("Unexpected outer type {:?} of kind {:?}", ty, k), |
There was a problem hiding this comment.
| k @ _ => bug!("Unexpected outer type {:?} of kind {:?}", ty, k), | |
| _ => bug!("unexpected outer type {ty:?}), |
Debug printing for Ty already redirects to TyKind printing.
|
|
||
| impl OuterTyKind { | ||
| /// Computes the relationship by providing the containing mir::Ty itself | ||
| fn from_outer_ty<'tcx>(ty: Ty<'tcx>) -> Self { |
There was a problem hiding this comment.
| fn from_outer_ty<'tcx>(ty: Ty<'tcx>) -> Self { | |
| fn from_ty<'tcx>(ty: Ty<'tcx>) -> Self { |
Nit: already have "outer" in OuterTyKind.
| /// but is needed because we don't change the lint's behavior yet | ||
| NoneThroughFnPtr, | ||
| /// Placeholder for properties that will be used eventually | ||
| UnusedVariant, |
There was a problem hiding this comment.
| UnusedVariant, | |
| Other, |
It's sort of used, because it indicates that the parent type is one of the allowed ones (and we panic on non-allowed). The comment can be also updated to "other allowed outer type".
| impl VisitorState { | ||
| /// From an existing state, compute the state of any subtype of the current type. | ||
| /// (General case. For the case where the current type is a function pointer, see `get_next_in_fnptr`.) | ||
| fn get_next<'tcx>(&self, current_ty: Ty<'tcx>) -> Self { |
There was a problem hiding this comment.
| fn get_next<'tcx>(&self, current_ty: Ty<'tcx>) -> Self { | |
| fn next(&self, current_ty: Ty<'_>) -> Self { |
get_is usually omitted in typical naming conventions because it's kind of useless.- some of the lifetimes here and below are probably unnecessary.
| /// (General case. For the case where the current type is a function pointer, see `get_next_in_fnptr`.) | ||
| fn get_next<'tcx>(&self, current_ty: Ty<'tcx>) -> Self { | ||
| assert!(!matches!(current_ty.kind(), ty::FnPtr(..))); | ||
| Self { |
There was a problem hiding this comment.
| Self { | |
| VisitorState { |
Could you avoid Self in non-generic code? At least in constructors like this.
There was a problem hiding this comment.
OK! I'm also changing the type annotation for OuterTyKind::from_ty's return and the RootUseFlags consts. Is this something you want?
edit: x fmt undoes that so...
| root_use_flags: self.root_use_flags, | ||
| outer_ty_kind: OuterTyKind::from_outer_ty(current_ty), | ||
| } | ||
| } |
There was a problem hiding this comment.
Mega-nit: space between functions.
| /// Generate the state for an "outermost" type that needs to be checked | ||
| fn entry_point(root_use_flags: RootUseFlags) -> Self { | ||
| Self { root_use_flags, outer_ty_kind: OuterTyKind::None } | ||
| } |
There was a problem hiding this comment.
I'd inline and remove this function, it's trivial and is only used twice.
| } | ||
|
|
||
| /// Get the proper visitor state for a static variable's type | ||
| fn static_var() -> Self { |
There was a problem hiding this comment.
| fn static_var() -> Self { | |
| fn static_entry_point() -> Self { |
Nit: I don't think these are called "variables" often in Rust.
Also for consistency with fn_entry_point.
| } | ||
|
|
||
| /// Whether the type itself is the type of a function argument or return type. | ||
| fn is_direct_in_function(&self) -> bool { |
There was a problem hiding this comment.
I'd rather not introduce simple functions that are used once, this one and is_direct_function_return can be inlined and removed.
| } | ||
|
|
||
| /// Get the proper visitor state for a given function's arguments or return type. | ||
| fn entry_point_from_fnmode(fn_mode: CItemKind, fn_pos: FnPos) -> Self { |
There was a problem hiding this comment.
| fn entry_point_from_fnmode(fn_mode: CItemKind, fn_pos: FnPos) -> Self { | |
| fn fn_entry_point(fn_mode: CItemKind, fn_pos: FnPos) -> Self { |
For consistency with static_entry_point.
The _from_fnmode suffix would make sense if there were other simpler fn_entry, not from fn mode.
Another user-transparent change, unifying outer-type information and the existing VisitorState flags.
ac62a57 to
405a44a
Compare
View all comments
This is the second PR in an effort to split #134697 (refactor plus overhaul of the ImproperCTypes family of lints) into individually-mergeable parts.
Contains the changes of the first PR, and splits the core type checking function into several bits, each focused on a specific aspect of FFI-safety.
Some logic which was outside of said core function was also moved into the new functions.
Superset of: #146271