Co-authored-by: Jacob Lifshay <programmerjake@gmail.com>

Co-authored-by: Waffle Maybe <waffle.lapkin@gmail.com>

Co-authored-by: Jacob Lifshay <programmerjake@gmail.com>

Co-authored-by: Waffle Maybe <waffle.lapkin@gmail.com>

During the FCP, people noticed that the wording of the drawback
probably fit better with an earlier draft of this RFC.  Let's
incorporate that feedback before merging.

(Thanks to Waffle for raising this point.)

Let's improve the wording related to where the `safe` keyword is
allowed.

(Thanks to Waffle for raising this point.)

(Thanks to spastorino for noticing this.)

An incorrect declaration in an `extern` block may cause undefined
behavior in the resulting program.  Let's clarify that in the text.

(Thanks to Waffle for raising this point.)

This RFC suggests replacements to text within the Rust Reference.
Let's clarify where those sections are.

(Thanks to Waffle for raising this point.)

There's a long history of discussion on how incorrect declarations in
`extern` blocks might cause UB in programs compiled using LLVM.  Let's
link to one of the issues in that history.

(Thanks to madsmtm for raising this question, and to RalfJ for
providing this citation.)

This RFC means to specify that we will *eventually* issue a lint in
all editions when `extern` is not prefixed with `unsafe`.  Let's
specify this more clearly.

(Thanks to Waffle and joshtriplett for raising this point.)

This document had a mix of line wrapping styles.  Let's consistently
unwrap the lines.

The term "undefined behavior" is not a proper noun, so let's make this
lowercase.

As this RFC was reviewed in the GitHub thread, many alternatives were
proposed and questions raised.  As those of us who were a bit too
close to it were cursed with knowledge, the rationale for rejecting
these alternatives were not fully articulated and not all of these
questions were clearly answered.

Let's better document these alternatives, the rationale for rejecting
each, and the answers to various known questions.

(Thanks to GoldsteinE, madsmtm, kennytm, samih, and tmccombs for
raising these alternatives and questions.)

One possibility we should mention is that of changing the behavior of
LLVM and then not adding `unsafe extern`, so let's mention that.

(Thanks to RalfJ for raising this point.)

Even if the C standard allows for what LLVM is doing, we could still
conceivably fix LLVM.  In the text, let's draw this out a bit more
finely.

(Thanks to RalfJ for raising this point.)

When people migrate to the new edition, if they have turned up the
severity of the `unsafe_code` lint and they have `extern` blocks that
need to be marked `unsafe`, they will see this lint as intended.
Let's make a note of that.

(Thanks to kennytm for raising this point.)

This RFC had used as one motivation that undefined behavior can
currently result simply from having an incorrect `extern` block even
if the items within are not used from Rust code.

This motivation was not cited in the lang team's 2023-10-11 consensus
for how and why to proceed with this RFC, and it's possible that we
may be able to resolve this issue in other ways, so let's remove that
motivation from this RFC.

(Thanks to RalfJ for raising this point and suggesting this.)

The 2023-10-11 consensus from lang on how to move forward included
that the `safe` and `unsafe` keywords would be optional within an
`unsafe extern` block.

The reference-level section correctly followed this consensus, but the
guide-level section did not, and suggested that annotating items with
these keywords was required.  Let's fix that.