@@ -37,7 +37,7 @@ An example of an empty type is `enum Empty { }`.
37
37
E0003 : r##"
38
38
Not-a-Number (NaN) values cannot be compared for equality and hence can never
39
39
match the input to a match expression. To match against NaN values, you should
40
- instead use the `is_nan` method in a guard, as in: x if x.is_nan() => ...
40
+ instead use the `is_nan` method in a guard, as in: ` x if x.is_nan() => ...`
41
41
"## ,
42
42
43
43
E0004 : r##"
@@ -71,7 +71,7 @@ failure.
71
71
E0007 : r##"
72
72
This error indicates that the bindings in a match arm would require a value to
73
73
be moved into more than one location, thus violating unique ownership. Code like
74
- the following is invalid as it requires the entire Option<String> to be moved
74
+ the following is invalid as it requires the entire ` Option<String>` to be moved
75
75
into a variable called `op_string` while simultaneously requiring the inner
76
76
String to be moved into a variable called `s`.
77
77
@@ -99,10 +99,10 @@ match Some("hi".to_string()) {
99
99
}
100
100
```
101
101
102
- The variable `s` has type String, and its use in the guard is as a variable of
103
- type String. The guard code effectively executes in a separate scope to the body
104
- of the arm, so the value would be moved into this anonymous scope and therefore
105
- become unavailable in the body of the arm. Although this example seems
102
+ The variable `s` has type ` String` , and its use in the guard is as a variable of
103
+ type ` String` . The guard code effectively executes in a separate scope to the
104
+ body of the arm, so the value would be moved into this anonymous scope and
105
+ therefore become unavailable in the body of the arm. Although this example seems
106
106
innocuous, the problem is most clear when considering functions that take their
107
107
argument by value.
108
108
@@ -140,7 +140,8 @@ match x {
140
140
```
141
141
142
142
You have two solutions:
143
- 1. Bind the pattern's values the same way:
143
+
144
+ Solution #1: Bind the pattern's values the same way.
144
145
145
146
```
146
147
struct X { x: (), }
@@ -153,8 +154,9 @@ match x {
153
154
}
154
155
```
155
156
156
- 2. Implement the `Copy` trait for the X structure (however, please
157
- keep in mind that the first solution should be preferred!):
157
+ Solution #2: Implement the `Copy` trait for the `X` structure.
158
+
159
+ However, please keep in mind that the first solution should be preferred.
158
160
159
161
```
160
162
#[derive(Clone, Copy)]
@@ -258,11 +260,13 @@ functions via FFI or marked as unsafe, is potentially dangerous and disallowed
258
260
by safety checks. As such, those safety checks can be temporarily relaxed by
259
261
wrapping the unsafe instructions inside an `unsafe` block. For instance:
260
262
263
+ ```
261
264
unsafe fn f() { return; }
262
265
263
266
fn main() {
264
267
unsafe { f(); }
265
268
}
269
+ ```
266
270
267
271
See also http://doc.rust-lang.org/book/unsafe.html
268
272
"## ,
@@ -313,8 +317,8 @@ it around as usual.
313
317
314
318
E0162 : r##"
315
319
An if-let pattern attempts to match the pattern, and enters the body if the
316
- match was succesful . If the match is irrefutable (when it cannot fail to match),
317
- use a regular `let`-binding instead. For instance:
320
+ match was successful . If the match is irrefutable (when it cannot fail to
321
+ match), use a regular `let`-binding instead. For instance:
318
322
319
323
```
320
324
struct Irrefutable(i32);
@@ -334,8 +338,8 @@ foo(x);
334
338
335
339
E0165 : r##"
336
340
A while-let pattern attempts to match the pattern, and enters the body if the
337
- match was succesful . If the match is irrefutable (when it cannot fail to match),
338
- use a regular `let`-binding inside a `loop` instead. For instance:
341
+ match was successful . If the match is irrefutable (when it cannot fail to
342
+ match), use a regular `let`-binding inside a `loop` instead. For instance:
339
343
340
344
```
341
345
struct Irrefutable(i32);
@@ -374,7 +378,7 @@ match m {
374
378
```
375
379
376
380
If you don't qualify the names, the code will bind new variables named "GET" and
377
- "POST" instead. This behavior is likely not what you want, so rustc warns when
381
+ "POST" instead. This behavior is likely not what you want, so ` rustc` warns when
378
382
that happens.
379
383
380
384
Qualified names are good practice, and most code works well with them. But if
@@ -403,16 +407,16 @@ const Y: u32 = X;
403
407
"## ,
404
408
405
409
E0267 : r##"
406
- This error indicates the use of loop keyword (break or continue) inside a
407
- closure but outside of any loop. Break and continue can be used as normal
408
- inside closures as long as they are also contained within a loop. To halt the
409
- execution of a closure you should instead use a return statement.
410
+ This error indicates the use of a loop keyword (` break` or ` continue` ) inside a
411
+ closure but outside of any loop. Break and continue can be used as normal inside
412
+ closures as long as they are also contained within a loop. To halt the execution
413
+ of a closure you should instead use a return statement.
410
414
"## ,
411
415
412
416
E0268 : r##"
413
- This error indicates the use of loop keyword (break or continue) outside of a
414
- loop. Without a loop to break out of or continue in, no sensible action can be
415
- taken.
417
+ This error indicates the use of a loop keyword (` break` or ` continue` ) outside
418
+ of a loop. Without a loop to break out of or continue in, no sensible action can
419
+ be taken.
416
420
"## ,
417
421
418
422
E0296 : r##"
@@ -507,7 +511,7 @@ match Some("hi".to_string()) {
507
511
}
508
512
```
509
513
510
- The `op_string_ref` binding has type &Option<&String> in both cases.
514
+ The `op_string_ref` binding has type ` &Option<&String>` in both cases.
511
515
512
516
See also https://github.com/rust-lang/rust/issues/14587
513
517
"## ,
0 commit comments