fix wrong return type being used

Author: folkertdev

text/0000-cmse-calling-conventions.md

@@ -58,17 +58,17 @@ type T0 = extern "cmse-nonsecure-call" fn(_: i32, _: i32, _: i32, _: i32) -> i32
 type T1 = extern "cmse-nonsecure-call" fn(_: i64, _: i64) -> i64;
 
 #[repr(transparent)] struct U64(u64);
-type T3 = extern "cmse-nonsecure-call" fn() -> U64;
+type T2 = extern "cmse-nonsecure-call" fn() -> U64;
 
 // Invalid: too many argument registers used
-type T1 = extern "cmse-nonsecure-call" fn(_: i64, _: u8, _: u8, _: u8) -> i64;
+type T3 = extern "cmse-nonsecure-call" fn(_: i64, _: u8, _: u8, _: u8) -> i64;
 
 // Invalid: return type too large
-type T1 = extern "cmse-nonsecure-call" fn() -> i128;
+type T4 = extern "cmse-nonsecure-call" fn() -> i128;
 
 // Invalid: return type does not fit in one register, and is not abi-compatible with a 64-bit scalar
-#[repr(C)] struct I64(i64);
-type T2 = extern "cmse-nonsecure-call" fn(_: i64, _: i64) -> i64;
+#[repr(C)] struct WrappedI64(i64);
+type T5 = extern "cmse-nonsecure-call" fn(_: i64, _: i64) -> WrappedI64;
 ```
 
 An error is emitted when the program contains a signature that violates the calling convention's constraints:
@@ -124,7 +124,7 @@ Evaluating entry functions during constant evaluation is valid. The context swit
 
 The `cmse-nonsecure-call` calling convention can only be used on function pointers, which cannot be evaluated during constant evaluation.
 
-Miri is not a register machine, so the clearing of registers is not relevant. The context switching also does not need to be considered, because a Miri input program cannot use FFI and therefore cannot cross the secure boundary. Any attempt to do so would rely on a transmute or similar and would for that reason be unsound. 
+Miri is not a register machine, so the clearing of registers is not relevant. The context switching also does not need to be considered, because a Miri input program cannot use FFI and therefore cannot cross the secure boundary. Any attempt to do so would rely on a transmute or similar and would for that reason be unsound.
 ### Warn on partially uninitialized values crossing the secure boundary
 
 Unions and types with padding or niches can contain uninitialized memory, and this uninitialized memory can contain stale secure information. Clang warns when union values cross the security boundary (see https://godbolt.org/z/vq9xnrnEs), and rust does the same.
@@ -163,7 +163,7 @@ extern "cmse-nonsecure-entry" fn padded_struct() -> PaddedStruct {
 A `cmse-nonsecure-call` function call will emit a warning when any of its arguments has a partially uninitialized type, and a `cmse-nonsecure-entry` function warns at any (implicit) return when the return type may be partially uninitialized.
 
 Ultimately guaranteeing the security properties of the system is up to the programmer, but warning on types with potentially uninitialized memory is a helpful signal that the compiler can provide.
-## Background 
+## Background
 
 Additional background on what these calling conventions do, and how they are meant to be used. This information is not strictly required to understand the RFC, but has informed the design and may explain certain design choices.
 
@@ -284,7 +284,7 @@ The [`cortex_m`](https://docs.rs/cortex-m/latest/cortex_m/cmse/index.html) crate
 # Future possibilities
 [future-possibilities]: #future-possibilities
 
-## Lint on references crossing the secure boundary 
+## Lint on references crossing the secure boundary
 
 The secure application should never accept a reference because there is no guarantee that a hostile non-secure application does not provide an invalid value (`NULL`, not properly aligned, etc.). There are other types with layout assumptions (e.g. `NonZeroU64` and friends) that are almost certainly invalid for a secure application to accept.
 
@@ -298,7 +298,7 @@ A suggestion that was floated is to provide some mechanism to ensure that a valu
 One potential method is to extend the`repr` attribute with an option that adds fields where padding is needed internally. These user-hidden padding fields would be zeroed upon creation.
 ```rust
 #[repr(C, align(8), initialized)]
-struct Foo { 
+struct Foo {
 	a: u8,
 	// implicit _padding0: [u8; 1],
 	b: u16,