bors 1ead4761e9 Auto merge of #119878 - scottmcm:inline-always-unwrap, r=workingjubilee
Tune the inlinability of `unwrap`

Fixes #115463
cc `@thomcc`

This tweaks `unwrap` on ~~`Option` &~~ `Result` to be two parts:
- `#[inline(always)]` for checking the discriminant
- `#[cold]` for actually panicking

The idea here is that checking the discriminant on a `Result` ~~or `Option`~~ should always be trivial enough to be worth inlining, even in `opt-level=z`, especially compared to passing it to a function.

As seen in the issue and codegen test, this will hopefully help particularly for things like `.try_into().unwrap()`s that are actually infallible, but in a way that's only visible with the inlining.

EDIT: I've restricted this to `Result` to avoid combining effects
2024-01-15 09:20:46 +00:00
..
2023-07-27 14:44:13 -07:00
2023-07-29 18:34:41 -07:00
2024-01-06 14:26:37 +01:00
2023-09-02 13:42:58 +02:00
2023-07-27 14:44:13 -07:00
2023-08-07 14:11:03 +02:00
2023-07-27 14:44:13 -07:00
2023-07-27 14:44:13 -07:00
2023-07-27 14:44:13 -07:00
2023-10-20 21:14:01 +00:00
2023-07-27 14:44:13 -07:00
2023-10-08 16:45:45 +00:00
2023-07-27 14:44:13 -07:00
2023-07-08 15:38:40 +02:00
2023-11-11 19:48:47 -08:00
2023-07-27 14:44:13 -07:00
2023-07-27 14:44:13 -07:00
2023-07-27 14:44:13 -07:00
2023-07-27 14:44:13 -07:00
2023-07-27 14:44:13 -07:00
2023-07-27 14:44:13 -07:00
2023-08-17 18:28:33 +00:00
2023-07-27 14:44:13 -07:00
2023-07-27 14:44:13 -07:00
2023-07-27 14:44:13 -07:00
2023-07-08 15:38:40 +02:00
2023-07-27 14:44:13 -07:00
2024-01-02 15:03:14 +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