Fix an inconsistency in naked functions ABI spec

We had previously update the requirements in the first section, but
forgot to match the explanatory paragraph to match.

Author: npmccallum

text/2972-constrained-naked.md

@@ -46,7 +46,7 @@ Further, since many platforms store the return address on the stack, it is the r
 
 Any attempt to use function arguments, even as operands, may cause stack access or modification. Likewise, any register operands may cause the compiler to attempt to preserve registers on the stack. Since the function has no prologue, this is problematic. To avoid this problem, we simply refuse to allow the use of any function arguments in Rust.
 
-If this were the end of the story, naked functions would not be very useful. In order to re-enable access to the function arguments, the compiler ensures that the initial state of the registers in the `asm!()` statement conform to the function's calling convention. This allows hand-crafted assembly access to the function arguments through the calling convention. Since the `extern "Rust"` calling convention is undefined, its use is disallowed and an alternative, well-defined calling convention must be specified. Likewise, since the `asm!()` statement can access the function arguments through the calling convention, the arguments themselves must be FFI safe to ensure that they can be reliably accessed from assembly.
+If this were the end of the story, naked functions would not be very useful. In order to re-enable access to the function arguments, the compiler ensures that the initial state of the registers in the `asm!()` statement conform to the function's calling convention. This allows hand-crafted assembly access to the function arguments through the calling convention. Since the `extern "Rust"` calling convention is undefined, its use is discouraged and an alternative, well-defined calling convention should be specified. Likewise, since the `asm!()` statement can access the function arguments through the calling convention, the arguments themselves should be FFI safe to ensure that they can be reliably accessed from assembly.
 
 Because naked functions depend upon the calling convention so heavily, inlining of these functions would make code generation extremely difficult. Therefore, we disallow inlining.