introduce copy_drop_in_place lint to rustc_lint

[EvoPot]

This PR introduces the copy_drop_in_place lint that activates when std::ptr::drop_in_place is called with a pointer to a Copy type.

See issue #160127

r? rust-lang/diagnostics

[rust-log-analyzer]

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

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

tests/pass/shims/x86/rounding-error.rs ... ok
tests/pass/shims/x86/intrinsics-x86-gfni.rs ... ok

FAILED TEST: tests/pass/drop_in_place.rs
command: MIRI_ENV_VAR_TEST="0" MIRI_TEMP="/tmp/miri-uitest-rEtagw" RUST_BACKTRACE="1" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/release/miri" "--error-format=json" "-Dwarnings" "-Dunused" "-Ainternal_features" "-Zui-testing" "--sysroot=/checkout/obj/build/x86_64-unknown-linux-gnu/miri-sysroot" "--out-dir" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/tmp/miri_ui/0/tests/pass" "tests/pass/drop_in_place.rs" "--edition" "2021"

error: test got exit status: 1, but expected 0
 = note: compilation failed, but was expected to succeed

error: no output was expected
Execute `./miri test --bless` to update `tests/pass/drop_in_place.stderr` to the actual output
+++ <stderr output>
error: calls to `std::ptr::drop_in_place` with a pointer to a Copy type does nothing
##[error]  --> tests/pass/drop_in_place.rs:9:14
   |
LL |     unsafe { ptr::drop_in_place(&mut not_a_bool as *mut u8 as *mut bool) };
   |              ^^^^^^^^^^^^^^^^^^^---------------------------------------^
   |                                 |
   |                                 argument has type `*mut bool`
   |
   = note: `-D copy-drop-in-place` implied by `-D warnings`
---
full stderr:
error: calls to `std::ptr::drop_in_place` with a pointer to a Copy type does nothing
##[error]  --> tests/pass/drop_in_place.rs:9:14
   |
LL |     unsafe { ptr::drop_in_place(&mut not_a_bool as *mut u8 as *mut bool) };
   |              ^^^^^^^^^^^^^^^^^^^---------------------------------------^
   |                                 |
   |                                 argument has type `*mut bool`
   |
   = note: `-D copy-drop-in-place` implied by `-D warnings`
---

Location:
   /cargo/registry/src/index.crates.io-1949cf8c6b5b557f/ui_test-0.30.7/src/lib.rs:365

Backtrace omitted. Run with RUST_BACKTRACE=1 environment variable to display it.
Run with RUST_BACKTRACE=full to include source snippets.
error: test failed, to rerun pass `--test ui`

Caused by:
  process didn't exit successfully: `/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/release/build/miri/855274d73082e308/out/ui-855274d73082e308` (exit status: 1)
Bootstrap failed while executing `test --stage 2 src/tools/miri src/tools/miri/cargo-miri`
Currently active steps:
test::Miri { target: x86_64-unknown-linux-gnu } at src/bootstrap/src/core/build_steps/test.rs:696
Command `/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo test --target x86_64-unknown-linux-gnu -Zbinary-dep-depinfo -j 4 -Zroot-dir=/checkout --locked --color=always --profile=release --manifest-path /checkout/src/tools/miri/Cargo.toml -- [workdir=/checkout]` failed with exit code 1
Created at: src/bootstrap/src/core/build_steps/tool.rs:197:21
Executed at: src/bootstrap/src/core/build_steps/test.rs:770:19

Command has failed. Rerun with -v to see more details.
Build completed unsuccessfully in 0:44:52
  local time: Thu Jul 30 17:34:48 UTC 2026
  network time: Thu, 30 Jul 2026 17:34:48 GMT
##[error]Process completed with exit code 1.
##[group]Run echo "disk usage:"

[Urgau]

Seems like we raced each other 😄 I just opened #160229 to fix it.

Happy to drop my PR and help you.

[EvoPot]

Seems like we raced each other 😄 I just opened #160229 to fix it.

Happy to drop my PR and help you.

Is that really okay? Mine introduces a new lint and doesn't work on methods. I personally think yours should go through.

[EvoPot]

Update : I closed it away to not confuse maintainers

[Urgau]

Is that really okay?

I think so, lints are allowed to change, and in this case it merely extends the lint to do the same thing across an indirection; but I've nominated the lint for the language team to consider it (with the I-lang-nominated label).