Skip to content
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

Add a special case for CStr/CString in the improper_ctypes lint #120176

Closed
wants to merge 1 commit into from

Conversation

Flying-Toast
Copy link
Contributor

Instead of saying to "consider adding a #[repr(C)] or #[repr(transparent)] attribute to this struct", we now tell users to "Use *const ffi::c_char instead, and pass the value from CStr::as_ptr()" when the type involved is a CStr or a CString.

Inspired by a conversation on the #beginners Discord channel.

@rustbot
Copy link
Collaborator

rustbot commented Jan 20, 2024

r? @cjgillot

(rustbot has picked a reviewer for you, use r? to override)

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Jan 20, 2024
@Flying-Toast Flying-Toast force-pushed the cstr_in_ffi_lint branch 2 times, most recently from 5868441 to e607e99 Compare January 21, 2024 17:20
Copy link
Contributor

@asquared31415 asquared31415 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if there could be better suggestions that use binding.as_ptr() instead of CStr::as_ptr? I don't think it really matters though.

tests/ui/lint/lint-ctypes-cstr.rs Show resolved Hide resolved
tests/ui/lint/lint-ctypes-cstr.rs Show resolved Hide resolved
@Flying-Toast
Copy link
Contributor Author

I wonder if there could be better suggestions that use binding.as_ptr() instead of CStr::as_ptr? I don't think it really matters though.

binding.as_ptr() would require the error to be emitted at a call site, rather than at the definition/declaration though right? Or are you talking about including the literal string "binding" in the error?

@cjgillot cjgillot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 10, 2024
@Flying-Toast Flying-Toast force-pushed the cstr_in_ffi_lint branch 2 times, most recently from d80eb55 to 889a1fb Compare March 18, 2024 21:42
@Flying-Toast
Copy link
Contributor Author

r? @cjgillot

@rustbot
Copy link
Collaborator

rustbot commented Mar 18, 2024

Could not assign reviewer from: cjgillot.
User(s) cjgillot are either the PR author, already assigned, or on vacation, and there are no other candidates.
Use r? to specify someone else to assign.

@bors
Copy link
Contributor

bors commented Mar 22, 2024

☔ The latest upstream changes (presumably #122852) made this pull request unmergeable. Please resolve the merge conflicts.

@rustbot
Copy link
Collaborator

rustbot commented Mar 23, 2024

Some changes occurred in src/tools/cargo

cc @ehuss

@Flying-Toast
Copy link
Contributor Author

Oops, didn't mean to touch all the submodules

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

Instead of saying to "consider adding a `#[repr(C)]` or `#[repr(transparent)]` attribute to this struct", we now tell users to "Use `*const ffi::c_char` instead, and pass the value from `CStr::as_ptr()`" when the type involved is a `CStr` or a `CString`.

Inspired by a conversation on the #beginners Discord channel.
@Dylan-DPC Dylan-DPC added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Apr 24, 2024
@cjgillot
Copy link
Contributor

cjgillot commented May 1, 2024

@bors r+

@bors
Copy link
Contributor

bors commented May 1, 2024

📌 Commit 4ea52f1 has been approved by cjgillot

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 1, 2024
bors added a commit to rust-lang-ci/rust that referenced this pull request May 1, 2024
…illot

Add a special case for CStr/CString in the improper_ctypes lint

Instead of saying to "consider adding a `#[repr(C)]` or `#[repr(transparent)]` attribute to this struct", we now tell users to "Use `*const ffi::c_char` instead, and pass the value from `CStr::as_ptr()`" when the type involved is a `CStr` or a `CString`.

Inspired by a conversation on the #beginners Discord channel.
@bors
Copy link
Contributor

bors commented May 1, 2024

⌛ Testing commit 4ea52f1 with merge 0f5b39f...

@rust-log-analyzer
Copy link
Collaborator

The job x86_64-gnu-llvm-18 failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

---- [ui] tests/ui/extern/extern-C-non-FFI-safe-arg-ice-52334.rs stdout ----
diff of stderr:

- warning: `extern` fn uses type `[i8 or u8 (arch dependant)]`, which is not FFI-safe
+ warning: `extern` fn uses type `CStr`, which is not FFI-safe
3    |
4 LL | type Foo = extern "C" fn(::std::ffi::CStr);

5    |            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not FFI-safe
5    |            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not FFI-safe
6    |
-    = help: consider using a raw pointer instead
-    = note: slices have no C equivalent
+    = help: consider passing a `*const std::ffi::c_char` instead, and use `CStr::as_ptr()`
+    = note: `CStr`/`CString` do not have a guaranteed layout
9    = note: `#[warn(improper_ctypes_definitions)]` on by default
10 
- warning: `extern` block uses type `[i8 or u8 (arch dependant)]`, which is not FFI-safe
+ warning: `extern` block uses type `CStr`, which is not FFI-safe
13    |
13    |
14 LL |     fn meh(blah: Foo);
15    |                  ^^^ not FFI-safe
16    |
-    = help: consider using a raw pointer instead
-    = help: consider using a raw pointer instead
-    = note: slices have no C equivalent
+    = help: consider passing a `*const std::ffi::c_char` instead, and use `CStr::as_ptr()`
+    = note: `CStr`/`CString` do not have a guaranteed layout
19    = note: `#[warn(improper_ctypes)]` on by default
21 warning: 2 warnings emitted


The actual stderr differed from the expected stderr.
The actual stderr differed from the expected stderr.
Actual stderr saved to /checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/extern/extern-C-non-FFI-safe-arg-ice-52334/extern-C-non-FFI-safe-arg-ice-52334.stderr
To update references, rerun the tests and pass the `--bless` flag
To only update this specific test, also pass `--test-args extern/extern-C-non-FFI-safe-arg-ice-52334.rs`

error: 1 errors occurred comparing output.
status: exit status: 0
command: env -u RUSTC_LOG_COLOR RUSTC_ICE="0" RUST_BACKTRACE="short" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage1/bin/rustc" "/checkout/tests/ui/extern/extern-C-non-FFI-safe-arg-ice-52334.rs" "-Zthreads=1" "-Zsimulate-remapped-rust-src-base=/rustc/FAKE_PREFIX" "-Ztranslate-remapped-path-to-local-path=no" "-Z" "ignore-directory-in-diagnostics-source-blocks=/cargo" "-Z" "ignore-directory-in-diagnostics-source-blocks=/checkout/vendor" "--sysroot" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage1" "--target=x86_64-unknown-linux-gnu" "--error-format" "json" "--json" "future-incompat" "-Ccodegen-units=1" "-Zui-testing" "-Zdeduplicate-diagnostics=no" "-Zwrite-long-types-to-disk=no" "-Cstrip=debuginfo" "--emit" "metadata" "-C" "prefer-dynamic" "--out-dir" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/extern/extern-C-non-FFI-safe-arg-ice-52334" "-A" "unused" "-A" "internal_features" "-Crpath" "-Cdebuginfo=0" "-Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/extern/extern-C-non-FFI-safe-arg-ice-52334/auxiliary"
--- stderr -------------------------------
--- stderr -------------------------------
warning: `extern` fn uses type `CStr`, which is not FFI-safe
   |
LL | type Foo = extern "C" fn(::std::ffi::CStr);
   |            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not FFI-safe
   |
   |
   = help: consider passing a `*const std::ffi::c_char` instead, and use `CStr::as_ptr()`
   = note: `CStr`/`CString` do not have a guaranteed layout
   = note: `#[warn(improper_ctypes_definitions)]` on by default

warning: `extern` block uses type `CStr`, which is not FFI-safe
   |
   |
LL |     fn meh(blah: Foo);
   |                  ^^^ not FFI-safe
   |
   = help: consider passing a `*const std::ffi::c_char` instead, and use `CStr::as_ptr()`
   = note: `CStr`/`CString` do not have a guaranteed layout
   = note: `#[warn(improper_ctypes)]` on by default
warning: 2 warnings emitted
------------------------------------------


@bors
Copy link
Contributor

bors commented May 1, 2024

💔 Test failed - checks-actions

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels May 1, 2024
@fmease
Copy link
Member

fmease commented May 3, 2024

(sync)
@bors r-

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 3, 2024
@oskgo
Copy link
Contributor

oskgo commented Jul 11, 2024

@Flying-Toast Can you update/fix the failing tests?

@Dylan-DPC
Copy link
Member

Closing this as inactive. Feel free to reöpen this pr or create a new pr if you get the time to work on this. Thanks

@Dylan-DPC Dylan-DPC closed this Aug 6, 2024
@Dylan-DPC Dylan-DPC added S-inactive Status: Inactive and waiting on the author. This is often applied to closed PRs. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Aug 6, 2024
@jieyouxu jieyouxu added the L-improper_ctypes Lint: improper_ctypes label Aug 6, 2024
workingjubilee added a commit to workingjubilee/rustc that referenced this pull request Aug 24, 2024
Add a special case for `CStr`/`CString` in the `improper_ctypes` lint

Revives rust-lang#120176. Just needed to bless a test and fix an argument, but seemed reasonable to me otherwise.

Instead of saying to "consider adding a `#[repr(C)]` or `#[repr(transparent)]` attribute to this struct", we now tell users to "Use `*const ffi::c_char` instead, and pass the value from `CStr::as_ptr()`" when the type involved is a `CStr` or a `CString`.

The suggestion is not made for `&mut CString` or `*mut CString`.

r? `@cjgillot` (since you were the reviewer of the original PR rust-lang#120176, but feel free to reroll)
workingjubilee added a commit to workingjubilee/rustc that referenced this pull request Aug 24, 2024
Add a special case for `CStr`/`CString` in the `improper_ctypes` lint

Revives rust-lang#120176. Just needed to bless a test and fix an argument, but seemed reasonable to me otherwise.

Instead of saying to "consider adding a `#[repr(C)]` or `#[repr(transparent)]` attribute to this struct", we now tell users to "Use `*const ffi::c_char` instead, and pass the value from `CStr::as_ptr()`" when the type involved is a `CStr` or a `CString`.

The suggestion is not made for `&mut CString` or `*mut CString`.

r? ``@cjgillot`` (since you were the reviewer of the original PR rust-lang#120176, but feel free to reroll)
workingjubilee added a commit to workingjubilee/rustc that referenced this pull request Aug 24, 2024
Add a special case for `CStr`/`CString` in the `improper_ctypes` lint

Revives rust-lang#120176. Just needed to bless a test and fix an argument, but seemed reasonable to me otherwise.

Instead of saying to "consider adding a `#[repr(C)]` or `#[repr(transparent)]` attribute to this struct", we now tell users to "Use `*const ffi::c_char` instead, and pass the value from `CStr::as_ptr()`" when the type involved is a `CStr` or a `CString`.

The suggestion is not made for `&mut CString` or `*mut CString`.

r? ```@cjgillot``` (since you were the reviewer of the original PR rust-lang#120176, but feel free to reroll)
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Aug 24, 2024
Add a special case for `CStr`/`CString` in the `improper_ctypes` lint

Revives rust-lang#120176. Just needed to bless a test and fix an argument, but seemed reasonable to me otherwise.

Instead of saying to "consider adding a `#[repr(C)]` or `#[repr(transparent)]` attribute to this struct", we now tell users to "Use `*const ffi::c_char` instead, and pass the value from `CStr::as_ptr()`" when the type involved is a `CStr` or a `CString`.

The suggestion is not made for `&mut CString` or `*mut CString`.

r? ````@cjgillot```` (since you were the reviewer of the original PR rust-lang#120176, but feel free to reroll)
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Aug 24, 2024
Add a special case for `CStr`/`CString` in the `improper_ctypes` lint

Revives rust-lang#120176. Just needed to bless a test and fix an argument, but seemed reasonable to me otherwise.

Instead of saying to "consider adding a `#[repr(C)]` or `#[repr(transparent)]` attribute to this struct", we now tell users to "Use `*const ffi::c_char` instead, and pass the value from `CStr::as_ptr()`" when the type involved is a `CStr` or a `CString`.

The suggestion is not made for `&mut CString` or `*mut CString`.

r? `````@cjgillot````` (since you were the reviewer of the original PR rust-lang#120176, but feel free to reroll)
tgross35 added a commit to tgross35/rust that referenced this pull request Aug 25, 2024
Add a special case for `CStr`/`CString` in the `improper_ctypes` lint

Revives rust-lang#120176. Just needed to bless a test and fix an argument, but seemed reasonable to me otherwise.

Instead of saying to "consider adding a `#[repr(C)]` or `#[repr(transparent)]` attribute to this struct", we now tell users to "Use `*const ffi::c_char` instead, and pass the value from `CStr::as_ptr()`" when the type involved is a `CStr` or a `CString`.

The suggestion is not made for `&mut CString` or `*mut CString`.

r? ``````@cjgillot`````` (since you were the reviewer of the original PR rust-lang#120176, but feel free to reroll)
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Aug 25, 2024
Rollup merge of rust-lang#128735 - jieyouxu:pr-120176-revive, r=cjgillot

Add a special case for `CStr`/`CString` in the `improper_ctypes` lint

Revives rust-lang#120176. Just needed to bless a test and fix an argument, but seemed reasonable to me otherwise.

Instead of saying to "consider adding a `#[repr(C)]` or `#[repr(transparent)]` attribute to this struct", we now tell users to "Use `*const ffi::c_char` instead, and pass the value from `CStr::as_ptr()`" when the type involved is a `CStr` or a `CString`.

The suggestion is not made for `&mut CString` or `*mut CString`.

r? ``````@cjgillot`````` (since you were the reviewer of the original PR rust-lang#120176, but feel free to reroll)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
L-improper_ctypes Lint: improper_ctypes S-inactive Status: Inactive and waiting on the author. This is often applied to closed PRs. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants