bors e4b9f86054 Auto merge of #109035 - scottmcm:ptr-read-should-know-undef, r=WaffleLapkin,JakobDegen
Ensure `ptr::read` gets all the same LLVM `load` metadata that dereferencing does

I was looking into `array::IntoIter` optimization, and noticed that it wasn't annotating the loads with `noundef` for simple things like `array::IntoIter<i32, N>`.  Trying to narrow it down, it seems that was because `MaybeUninit::assume_init_read` isn't marking the load as initialized (<https://rust.godbolt.org/z/Mxd8TPTnv>), which is unfortunate since that's basically its reason to exist.

The root cause is that `ptr::read` is currently implemented via the *untyped* `copy_nonoverlapping`, and thus the `load` doesn't get any type-aware metadata: no `noundef`, no `!range`.  This PR solves that by lowering `ptr::read(p)` to `copy *p` in MIR, for which the backends already do the right thing.

Fortuitiously, this also improves the IR we give to LLVM for things like `mem::replace`, and fixes a couple of long-standing bugs where `ptr::read` on `Copy` types was worse than `*`ing them.

Zulip conversation: <https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Move.20array.3A.3AIntoIter.20to.20ManuallyDrop/near/341189936>

cc `@erikdesjardins` `@JakobDegen` `@workingjubilee` `@the8472`

Fixes #106369
Fixes #73258
2023-03-15 11:44:12 +00:00
..
2023-01-17 16:23:22 +01:00
2023-01-17 16:23:22 +01:00
2023-02-25 21:43:25 +01:00
2023-01-11 20:42:13 -05:00
2023-01-17 16:23:22 +01:00
2023-01-17 16:23:22 +01:00
2023-01-17 16:23:22 +01:00
2023-01-17 16:23:22 +01:00
2023-01-17 16:23:22 +01:00
2023-02-25 21:43:25 +01:00
2023-01-17 16:23:22 +01:00
2023-02-18 21:35:02 +00:00
2023-01-17 16:23:22 +01:00
2023-01-17 16:23:22 +01:00
2023-01-17 16:23:22 +01:00
2023-02-14 19:21:58 -05:00
2023-01-17 16:23:22 +01:00
2023-01-17 16:23:22 +01:00
2023-01-17 16:23:22 +01:00
2023-01-17 16:23:22 +01:00
2023-01-17 16:23:22 +01:00
2023-02-14 19:21:58 -05:00
2023-01-17 16:23:22 +01:00
2023-01-17 16:23:22 +01:00

The files here use the LLVM FileCheck framework, documented at https://llvm.org/docs/CommandGuide/FileCheck.html.

One extension worth noting is the use of revisions as custom prefixes for FileCheck. If your codegen test has different behavior based on the chosen target or different compiler flags that you want to exercise, you can use a revisions annotation, like so:

// revisions: aaa bbb
// [bbb] compile-flags: --flags-for-bbb

After specifying those variations, you can write different expected, or explicitly unexpected output by using <prefix>-SAME: and <prefix>-NOT:, like so:

// CHECK: expected code
// aaa-SAME: emitted-only-for-aaa
// aaa-NOT:                        emitted-only-for-bbb
// bbb-NOT:  emitted-only-for-aaa
// bbb-SAME:                       emitted-only-for-bbb