In the effects checker, we were propagating the "has an unsafe use
site" outside of an `unsafe` expression. The result of this is that we
would not produce a warning for silly expressions like `unsafe unsafe
ptr.pointee`, where the first (outer) `unsafe` is unnecessary. Stop
propagating that bit so we properly diagnose the spurious "unsafe".
Fixes issue #82315 / rdar://153672668.
Check for unsafe constructs in all modes, so that we can emit the
"unsafe does not cover any unsafe constructs" warning consistently.
One does not need to write "unsafe" outside of strict memory safety
mode, but if you do... it needs to cover unsafe behavior.
Print diagnostic groups as part of the LLVM printer in the same manner as the
Swift one does, always. Make `-print-diagnostic-groups` an inert option, since we
always print diagnostic group names with the `[#GroupName]` syntax.
As part of this, we no longer render the diagnostic group name as part
of the diagnostic *text*, instead leaving it up to the diagnostic
renderer to handle the category appropriately. Update all of the tests
that were depending on `-print-diagnostic-groups` putting it into the
text to instead use the `{{documentation-file=<file name>}}`
diagnostic verification syntax.
This is a stop-gap solution to prevent spurious warnings when "unsafe"
expressions and for..in loops are used without strict memory safety.
The full answer is probably to determine where unsafe code is all the time,
so that we can still (correctly) diagnose "no unsafe operations" even outside
of strict memory safety mode.
