Skip to content

Commit 7c6e0c0

Browse files
committed
X-Links: Boolean Edition
This commit mostly adds links across the reference where things talked about the boolean type. I also normalized the language so that it always uses "boolean type". Other links were added as appropriate. This commit also changes a few "x expressions" to "x operands" for if and while expressions. The whole books needs this treatment, but while I was here, I did it for these sections. I also changed "`#[repr(C)]`" to "the C representation" in unions so that I could actually link to them without breaking linkcheck.
1 parent a1a711e commit 7c6e0c0

File tree

4 files changed

+25
-18
lines changed

4 files changed

+25
-18
lines changed

src/behavior-considered-undefined.md

+3-2
Original file line numberDiff line numberDiff line change
@@ -38,7 +38,7 @@ code.
3838
a function/primitive operation or returned from a function/primitive
3939
operation.
4040
The following values are invalid (at their respective type):
41-
* A value other than `false` (`0`) or `true` (`1`) in a `bool`.
41+
* A value other than `false` (`0`) or `true` (`1`) in a [`bool`].
4242
* A discriminant in an `enum` not included in the type definition.
4343
* A null `fn` pointer.
4444
* A value in a `char` which is a surrogate or above `char::MAX`.
@@ -77,7 +77,8 @@ cannot be bigger than `isize::MAX` bytes.
7777
> vice versa, undefined behavior in Rust can cause adverse affects on code
7878
> executed by any FFI calls to other languages.
7979
80-
[`const`]: items/constant-items.html
80+
[`bool`]: types/boolean.md
81+
[`const`]: items/constant-items.md
8182
[noalias]: http://llvm.org/docs/LangRef.html#noalias
8283
[pointer aliasing rules]: http://llvm.org/docs/LangRef.html#pointer-aliasing-rules
8384
[undef]: http://llvm.org/docs/LangRef.html#undefined-values

src/expressions/if-expr.md

+8-7
Original file line numberDiff line numberDiff line change
@@ -10,12 +10,12 @@
1010
> | _IfExpression_
1111
> | _IfLetExpression_ ) )<sup>\?</sup>
1212
13-
An `if` expression is a conditional branch in program control. The form of an
14-
`if` expression is a condition expression, followed by a consequent block, any
13+
An `if` expression is a conditional branch in program control. The syntax of an
14+
`if` expression is a condition operand, followed by a consequent block, any
1515
number of `else if` conditions and blocks, and an optional trailing `else`
16-
block. The condition expressions must have type `bool`. If a condition
17-
expression evaluates to `true`, the consequent block is executed and any
18-
subsequent `else if` or `else` block is skipped. If a condition expression
16+
block. The condition operands must have the [boolean type]. If a condition
17+
operand evaluates to `true`, the consequent block is executed and any
18+
subsequent `else if` or `else` block is skipped. If a condition operand
1919
evaluates to `false`, the consequent block is skipped and any subsequent `else
2020
if` condition is evaluated. If all `if` and `else if` conditions evaluate to
2121
`false` then any `else` block is executed. An if expression evaluates to the
@@ -52,8 +52,8 @@ assert_eq!(y, "Bigger");
5252
> | _IfLetExpression_ ) )<sup>\?</sup>
5353
5454
An `if let` expression is semantically similar to an `if` expression but in
55-
place of a condition expression it expects the keyword `let` followed by a
56-
pattern, an `=` and a [scrutinee] expression. If the value of the scrutinee
55+
place of a condition operand it expects the keyword `let` followed by a
56+
pattern, an `=` and a [scrutinee] operand. If the value of the scrutinee
5757
matches the pattern, the corresponding block will execute. Otherwise, flow
5858
proceeds to the following `else` block if it exists. Like `if` expressions,
5959
`if let` expressions have a value determined by the block that is evaluated.
@@ -158,4 +158,5 @@ if let PAT = ( EXPR || EXPR ) { .. }
158158
[_MatchArmPatterns_]: match-expr.md
159159
[_eRFCIfLetChain_]: https://github.com/rust-lang/rfcs/blob/master/text/2497-if-let-chains.md#rollout-plan-and-transitioning-to-rust-2018
160160
[`match` expression]: match-expr.md
161+
[boolean type]: ../types/boolean.md
161162
[scrutinee]: ../glossary.md#scrutinee

src/expressions/loop-expr.md

+4-3
Original file line numberDiff line numberDiff line change
@@ -47,9 +47,9 @@ have type compatible with the value of the `break` expression(s).
4747
> _PredicateLoopExpression_ :\
4848
> &nbsp;&nbsp; `while` [_Expression_]<sub>_except struct expression_</sub> [_BlockExpression_]
4949
50-
A `while` loop begins by evaluating the boolean loop conditional expression. If
51-
the loop conditional expression evaluates to `true`, the loop body block
52-
executes, then control returns to the loop conditional expression. If the loop
50+
A `while` loop begins by evaluating the [boolean] loop conditional operand. If
51+
the loop conditional operand evaluates to `true`, the loop body block
52+
executes, then control returns to the loop conditional operand. If the loop
5353
conditional expression evaluates to `false`, the `while` expression completes.
5454

5555
An example:
@@ -294,6 +294,7 @@ expression `()`.
294294
[_MatchArmPatterns_]: match-expr.md
295295
[_Pattern_]: ../patterns.md
296296
[`match` expression]: match-expr.md
297+
[boolean]: ../types/boolean.md
297298
[scrutinee]: ../glossary.md#scrutinee
298299
[temporary values]: ../expressions.md#temporaries
299300
[_LazyBooleanOperatorExpression_]: operator-expr.md#lazy-boolean-operators

src/items/unions.md

+10-6
Original file line numberDiff line numberDiff line change
@@ -47,13 +47,14 @@ let f = unsafe { u.f1 };
4747
Unions have no notion of an "active field". Instead, every union access just
4848
interprets the storage at the type of the field used for the access. Reading a
4949
union field reads the bits of the union at the field's type. Fields might have a
50-
non-zero offset (except when `#[repr(C)]` is used); in that case the bits
51-
starting at the offset of the fields are read. It is the programmer's
50+
non-zero offset (except when [the C representation] is used); in that case the
51+
bits starting at the offset of the fields are read. It is the programmer's
5252
responsibility to make sure that the data is valid at the field's type. Failing
53-
to do so results in undefined behavior. For example, reading the value `3` at
54-
type `bool` is undefined behavior. Effectively, writing to and then reading from
55-
a `#[repr(C)]` union is analogous to a [`transmute`] from the type used for
56-
writing to the type used for reading.
53+
to do so results in [undefined behavior]. For example, reading the value `3`
54+
through of a field of the [boolean type] is undefined behavior. Effectively,
55+
writing to and then reading from a union with [the C representation] is
56+
analogous to a [`transmute`] from the type used for writing to the type used for
57+
reading.
5758

5859
Consequently, all reads of union fields have to be placed in `unsafe` blocks:
5960

@@ -182,4 +183,7 @@ checking, etc etc etc).
182183
[_StructFields_]: structs.md
183184
[`transmute`]: ../../std/mem/fn.transmute.html
184185
[`Copy`]: ../../std/marker/trait.Copy.html
186+
[boolean type]: ../types/boolean.md
185187
[ManuallyDrop]: ../../std/mem/struct.ManuallyDrop.html
188+
[the C representation]: ../type-layout.md#reprc-unions
189+
[undefined behavior]: ../behavior-considered-undefined.html

0 commit comments

Comments
 (0)