bors 31d74fb24b Auto merge of #109220 - nikic:poison, r=cuviper
Use poison instead of undef

In cases where it is legal, we should prefer poison values over undef values.

This replaces undef with poison for aggregate construction and for uninhabited types. There are more places where we can likely use poison, but I wanted to stay conservative to start with.

In particular the aggregate case is important for newer LLVM versions, which are not able to handle an undef base value during early optimization due to poison-propagation concerns.

r? `@cuviper`
2023-03-24 15:39:40 +00:00
..
2023-03-20 10:25:29 +00:00
2023-01-17 16:23:22 +01:00
2023-03-22 15:15:41 -07:00
2023-03-20 10:25:29 +00: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-03-16 15:07:04 +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-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