improper ctypes: normalize return types and transparent structs #72890
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
(rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
This commit adds a test of the improper ctypes lint, checking that return type are normalized bethat return types are normalized before being checked for FFI-safety, and that transparent newtype wrappers are FFI-safe if the type being wrapped is FFI-safe. Signed-off-by: David Wood <david@davidtw.co>
davidtwco
force-pushed
the
issue-66202-normalize-and-transparent-improper-ctypes
branch
from
f0f13ff
to
65149f7
Compare
|
r? @varkor |
varkor
reviewed
Jun 9, 2020
src/librustc_lint/types.rs
Outdated
| if !is_static && self.check_for_array_ty(sp, ty) { | ||
| return; | ||
| } | ||
|
|
||
| // Don't report FFI errors for unit return types - not checking in `check_foreign_fn` so |
There was a problem hiding this comment.
I can't quite parse this sentence. Is it "we are now checking in"?
There was a problem hiding this comment.
Apparently this made sense to me when I wrote it - I understand past-me to have meant "we aren't checking in check_foreign_fn (where this check might have been expected) because we want to check after normalization".
There was a problem hiding this comment.
Pushed a hopefully clearer comment.
|
The changes look good to me. Just want to get clarification on that comment. Also cc @hanna-kruppe, who may have comments. |
This commit moves the check that skips unit return types to after where the return type has been normalized - therefore ensuring that FFI-safety lints are not emitted for types which normalize to unit. Signed-off-by: David Wood <david@davidtw.co>
This commit ensures that if a `repr(transparent)` newtype's only non-zero-sized field is FFI-safe then the newtype is also FFI-safe. Previously, ZSTs were ignored for the purposes of linting FFI-safety in transparent structs - thus, only the single non-ZST would be checked for FFI-safety. However, if the non-zero-sized field is a generic parameter, and is substituted for a ZST, then the type would be considered FFI-unsafe (as when every field is thought to be zero-sized, the type is considered to be "composed only of `PhantomData`" which is FFI-unsafe). In this commit, for transparent structs, the non-zero-sized field is identified (before any substitutions are applied, necessarily) and then that field's type (now with substitutions) is checked for FFI-safety (where previously it would have been skipped for being zero-sized in this case). To handle the case where the non-zero-sized field is a generic parameter, which is substituted for `()` (a ZST), and is being used as a return type - the `FfiUnsafe` result (previously `FfiPhantom`) is caught and silenced. Signed-off-by: David Wood <david@davidtw.co>
davidtwco
force-pushed
the
issue-66202-normalize-and-transparent-improper-ctypes
branch
from
65149f7
to
d4d3d7d
Compare
|
Thanks! @bors r+ rollup |
|
📌 Commit d4d3d7d has been approved by |
bors
added
S-waiting-on-bors
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Jun 10, 2020
Rollup of 9 pull requests Successful merges: - rust-lang#72706 (Add windows group to triagebot) - rust-lang#72789 (resolve: Do not suggest imports from the same module in which we are resolving) - rust-lang#72890 (improper ctypes: normalize return types and transparent structs) - rust-lang#72897 (normalize adt fields during structural match checking) - rust-lang#73005 (Don't create impl candidates when obligation contains errors) - rust-lang#73023 (Remove noisy suggestion of hash_map ) - rust-lang#73070 (Add regression test for const generic ICE in rust-lang#72819) - rust-lang#73157 (Don't lose empty `where` clause when pretty-printing) - rust-lang#73184 (Reoder order in which MinGW libs are linked to fix recent breakage) Failed merges: r? @ghost
davidtwco
deleted the
issue-66202-normalize-and-transparent-improper-ctypes
branch
davidtwco
added a commit
to davidtwco/rust
that referenced
this pull request
Jun 19, 2020
This commit applies the changes introduced in rust-lang#72890 to both enum variants and unions - where the logic prior to rust-lang#72890 was duplicated. Signed-off-by: David Wood <david@davidtw.co>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #66202.
See each commit individually (except the first which adds a test) for more detailed explanations on the changes made.
In summary, this PR ensures that return types are normalized before being checked for FFI-safety, and that transparent newtype wrappers are FFI-safe if the type being wrapped is FFI-safe (often true previously, but not if, after substitution, all types in a transparent newtype were zero sized).