Improve labeled blocks documentation

Relax ordering rules for `asm!` operands

"struct expressions can be in used in these situations" => "struct expressions can be used in these situations"

redundant word removed

Fix coding style in example: add space between module name and bracket

Explain typos in `asm!` can be unsound

Fix example for non-x86 targets

Document f16c target feature

…r block

Add an entry for macro_rules in the "Weak keywords" lexer block

…be incorrect

fixed minor error in a comment that annotated output of a proc macro

fix a typo

Update raw-dylib documentation for stabilization

Add documentation for debugger_visualizer attribute

Fix example code in `impl` docs

comments: Fix typo: inner -> outer

Co-authored-by: Eric Huss <eric@huss.org>

Co-authored-by: Eric Huss <eric@huss.org>

Add LoongArch to inline-assembly documentation

Fix inconsistent formatting of Disambiguating Function Calls example

Issue rust-lang/rust#27060 has been resolved, so it is no longer possible to safely create unaligned pointers to packed struct fields.

This was changed in rust-lang/rust#110141.

…path-syntax

fix incorrect syntax for type-paths

Document the ordering behavior of crate cfgs

Typo: 'a' to 'an' in destructors.md

Remove obsolete note about soundness hole in type-layout.md

str type: make sentence more readable

Typo: 'assingee' to 'assignee' in expressions.md

…ever

Remove doc of unstable feature of never type

Co-authored-by: Ralf Jung <post@ralfj.de>

Add CI trigger for merge queues.

Say that division by zero for primitive types panics

Co-authored-by: Ralf Jung <post@ralfj.de>

…r-change

Make unsafe keyword docs less confusing

Operator expressions: make the note about division by zero clearer.

mention the extra const UB

I personally found this description of UB confusing, since the use of
"reached" suggests that UB only happens for read bytes, and the
definition of immutability is not given, allowing for multiple
interpretations: does the "data" have to be immutable from the first
read? From the creation of the reference? Between reads from the
immutable accessor, but not otherwise? etc.

This clarifies the actual UB conditions, based on this Zulip
interaction:
https://rust-lang.zulipchat.com/#narrow/stream/136281-t-opsem/topic/What.20exactly.20are.20.22immutable.22.20and.20.22reached.22.20in.20shared.20ref.20UB.3F
and this reference discussion:
rust-lang#1227
in two ways:
  * The definition of "data" is clarified to be stated in terms of
    bytes, in a way that should avoid ambiguity about which bytes are
    considered. Based on the GH issue, this clarification should also
    allow for use of a `*mut` pointer through a shared reference, which
    is not in itself UB. Based on the Zulip issue, the definition
    includes padding bytes, which may be surprising.
  * The definition of immutability & mutation for a set of bytes is
    clarified to mean forbidding *all* non-0-byte writes.

This is part of the feedback on rust-lang#1385.

Ralf made the point that the immutability definition could be restated
solely in terms of bytes, which has the added benefit of no longer
requiring the note on padding (since it's a natural consequence of the
byte version.)

The new wording for shared references also clarifies the case of mutable
references behind shared ones, and reintroduces some of the transitivity
property that I removed in my previous commit. The wording is separate
from that for immutable bindings, since those don't have transitive
immutability.

This also bumps the definition of bytes pointed to by references and
pointers into its own subsection, so that it can be linked to by the UB
definition, to avoid duplication.

Co-authored-by: Ralf Jung <post@ralfj.de>

These changes should preserve the meaning of the contents.

Co-authored-by: Ralf Jung <post@ralfj.de>

…arification

Clarify UB around immutability & mutation

Fix merge queue building twice.

Clearly specify the `instruction_set` effects

Co-authored-by: Ryan Scheel <Ryan.havvy@gmail.com>

compile_fail is a dangerous thing to use since it doesn't validate which
error is generated (it could be something like a typo).

add section about implied bounds

Specify the bit validity and padding of the primitive numeric 
types, bool, char, and pointer and reference types.

Closes rust-lang#1291

The rust-reference implies that 64-bit types are aligned to 32-bit for
platforms with 32-bit addresses. This is not necessarily correct. Fix
the wording.

Note that there is no general rule how data-types greater than the
native address size are aligned. On most Unix'y systems, they use the
native alignment of the platform. However, the Windows ABI aligns them
to their size (up to at least 64-bit).

There are advantages for either of those decisions. But we should at
least make clear that there is no fixed rule for 32-bit platforms.

Signed-off-by: David Rheinsberg <david@readahead.eu>

Document thiscall abi

Mention the "none" target_os value

conditional-compilation.md: Mention the "none" target_os value