]> git.lizzy.rs Git - rust.git/blob - src/librustc_mir/diagnostics.rs
Auto merge of #54485 - arielb1:avoid-ctor-attrs, r=eddyb
[rust.git] / src / librustc_mir / diagnostics.rs
1 // Copyright 2015 The Rust Project Developers. See the COPYRIGHT
2 // file at the top-level directory of this distribution and at
3 // http://rust-lang.org/COPYRIGHT.
4 //
5 // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or
6 // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license
7 // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your
8 // option. This file may not be copied, modified, or distributed
9 // except according to those terms.
10
11 #![allow(non_snake_case)]
12
13 register_long_diagnostics! {
14
15
16 E0001: r##"
17 #### Note: this error code is no longer emitted by the compiler.
18
19 This error suggests that the expression arm corresponding to the noted pattern
20 will never be reached as for all possible values of the expression being
21 matched, one of the preceding patterns will match.
22
23 This means that perhaps some of the preceding patterns are too general, this
24 one is too specific or the ordering is incorrect.
25
26 For example, the following `match` block has too many arms:
27
28 ```
29 match Some(0) {
30     Some(bar) => {/* ... */}
31     x => {/* ... */} // This handles the `None` case
32     _ => {/* ... */} // All possible cases have already been handled
33 }
34 ```
35
36 `match` blocks have their patterns matched in order, so, for example, putting
37 a wildcard arm above a more specific arm will make the latter arm irrelevant.
38
39 Ensure the ordering of the match arm is correct and remove any superfluous
40 arms.
41 "##,
42
43 E0002: r##"
44 #### Note: this error code is no longer emitted by the compiler.
45
46 This error indicates that an empty match expression is invalid because the type
47 it is matching on is non-empty (there exist values of this type). In safe code
48 it is impossible to create an instance of an empty type, so empty match
49 expressions are almost never desired. This error is typically fixed by adding
50 one or more cases to the match expression.
51
52 An example of an empty type is `enum Empty { }`. So, the following will work:
53
54 ```
55 enum Empty {}
56
57 fn foo(x: Empty) {
58     match x {
59         // empty
60     }
61 }
62 ```
63
64 However, this won't:
65
66 ```compile_fail
67 fn foo(x: Option<String>) {
68     match x {
69         // empty
70     }
71 }
72 ```
73 "##,
74
75 E0004: r##"
76 This error indicates that the compiler cannot guarantee a matching pattern for
77 one or more possible inputs to a match expression. Guaranteed matches are
78 required in order to assign values to match expressions, or alternatively,
79 determine the flow of execution. Erroneous code example:
80
81 ```compile_fail,E0004
82 enum Terminator {
83     HastaLaVistaBaby,
84     TalkToMyHand,
85 }
86
87 let x = Terminator::HastaLaVistaBaby;
88
89 match x { // error: non-exhaustive patterns: `HastaLaVistaBaby` not covered
90     Terminator::TalkToMyHand => {}
91 }
92 ```
93
94 If you encounter this error you must alter your patterns so that every possible
95 value of the input type is matched. For types with a small number of variants
96 (like enums) you should probably cover all cases explicitly. Alternatively, the
97 underscore `_` wildcard pattern can be added after all other patterns to match
98 "anything else". Example:
99
100 ```
101 enum Terminator {
102     HastaLaVistaBaby,
103     TalkToMyHand,
104 }
105
106 let x = Terminator::HastaLaVistaBaby;
107
108 match x {
109     Terminator::TalkToMyHand => {}
110     Terminator::HastaLaVistaBaby => {}
111 }
112
113 // or:
114
115 match x {
116     Terminator::TalkToMyHand => {}
117     _ => {}
118 }
119 ```
120 "##,
121
122 E0005: r##"
123 Patterns used to bind names must be irrefutable, that is, they must guarantee
124 that a name will be extracted in all cases. Erroneous code example:
125
126 ```compile_fail,E0005
127 let x = Some(1);
128 let Some(y) = x;
129 // error: refutable pattern in local binding: `None` not covered
130 ```
131
132 If you encounter this error you probably need to use a `match` or `if let` to
133 deal with the possibility of failure. Example:
134
135 ```
136 let x = Some(1);
137
138 match x {
139     Some(y) => {
140         // do something
141     },
142     None => {}
143 }
144
145 // or:
146
147 if let Some(y) = x {
148     // do something
149 }
150 ```
151 "##,
152
153 E0007: r##"
154 This error indicates that the bindings in a match arm would require a value to
155 be moved into more than one location, thus violating unique ownership. Code
156 like the following is invalid as it requires the entire `Option<String>` to be
157 moved into a variable called `op_string` while simultaneously requiring the
158 inner `String` to be moved into a variable called `s`.
159
160 ```compile_fail,E0007
161 let x = Some("s".to_string());
162
163 match x {
164     op_string @ Some(s) => {}, // error: cannot bind by-move with sub-bindings
165     None => {},
166 }
167 ```
168
169 See also the error E0303.
170 "##,
171
172 E0008: r##"
173 Names bound in match arms retain their type in pattern guards. As such, if a
174 name is bound by move in a pattern, it should also be moved to wherever it is
175 referenced in the pattern guard code. Doing so however would prevent the name
176 from being available in the body of the match arm. Consider the following:
177
178 ```compile_fail,E0008
179 match Some("hi".to_string()) {
180     Some(s) if s.len() == 0 => {}, // use s.
181     _ => {},
182 }
183 ```
184
185 The variable `s` has type `String`, and its use in the guard is as a variable of
186 type `String`. The guard code effectively executes in a separate scope to the
187 body of the arm, so the value would be moved into this anonymous scope and
188 therefore becomes unavailable in the body of the arm.
189
190 The problem above can be solved by using the `ref` keyword.
191
192 ```
193 match Some("hi".to_string()) {
194     Some(ref s) if s.len() == 0 => {},
195     _ => {},
196 }
197 ```
198
199 Though this example seems innocuous and easy to solve, the problem becomes clear
200 when it encounters functions which consume the value:
201
202 ```compile_fail,E0008
203 struct A{}
204
205 impl A {
206     fn consume(self) -> usize {
207         0
208     }
209 }
210
211 fn main() {
212     let a = Some(A{});
213     match a {
214         Some(y) if y.consume() > 0 => {}
215         _ => {}
216     }
217 }
218 ```
219
220 In this situation, even the `ref` keyword cannot solve it, since borrowed
221 content cannot be moved. This problem cannot be solved generally. If the value
222 can be cloned, here is a not-so-specific solution:
223
224 ```
225 #[derive(Clone)]
226 struct A{}
227
228 impl A {
229     fn consume(self) -> usize {
230         0
231     }
232 }
233
234 fn main() {
235     let a = Some(A{});
236     match a{
237         Some(ref y) if y.clone().consume() > 0 => {}
238         _ => {}
239     }
240 }
241 ```
242
243 If the value will be consumed in the pattern guard, using its clone will not
244 move its ownership, so the code works.
245 "##,
246
247 E0009: r##"
248 In a pattern, all values that don't implement the `Copy` trait have to be bound
249 the same way. The goal here is to avoid binding simultaneously by-move and
250 by-ref.
251
252 This limitation may be removed in a future version of Rust.
253
254 Erroneous code example:
255
256 ```compile_fail,E0009
257 struct X { x: (), }
258
259 let x = Some((X { x: () }, X { x: () }));
260 match x {
261     Some((y, ref z)) => {}, // error: cannot bind by-move and by-ref in the
262                             //        same pattern
263     None => panic!()
264 }
265 ```
266
267 You have two solutions:
268
269 Solution #1: Bind the pattern's values the same way.
270
271 ```
272 struct X { x: (), }
273
274 let x = Some((X { x: () }, X { x: () }));
275 match x {
276     Some((ref y, ref z)) => {},
277     // or Some((y, z)) => {}
278     None => panic!()
279 }
280 ```
281
282 Solution #2: Implement the `Copy` trait for the `X` structure.
283
284 However, please keep in mind that the first solution should be preferred.
285
286 ```
287 #[derive(Clone, Copy)]
288 struct X { x: (), }
289
290 let x = Some((X { x: () }, X { x: () }));
291 match x {
292     Some((y, ref z)) => {},
293     None => panic!()
294 }
295 ```
296 "##,
297
298 E0030: r##"
299 When matching against a range, the compiler verifies that the range is
300 non-empty.  Range patterns include both end-points, so this is equivalent to
301 requiring the start of the range to be less than or equal to the end of the
302 range.
303
304 For example:
305
306 ```compile_fail
307 match 5u32 {
308     // This range is ok, albeit pointless.
309     1 ..= 1 => {}
310     // This range is empty, and the compiler can tell.
311     1000 ..= 5 => {}
312 }
313 ```
314 "##,
315
316 E0158: r##"
317 `const` and `static` mean different things. A `const` is a compile-time
318 constant, an alias for a literal value. This property means you can match it
319 directly within a pattern.
320
321 The `static` keyword, on the other hand, guarantees a fixed location in memory.
322 This does not always mean that the value is constant. For example, a global
323 mutex can be declared `static` as well.
324
325 If you want to match against a `static`, consider using a guard instead:
326
327 ```
328 static FORTY_TWO: i32 = 42;
329
330 match Some(42) {
331     Some(x) if x == FORTY_TWO => {}
332     _ => {}
333 }
334 ```
335 "##,
336
337 E0162: r##"
338 An if-let pattern attempts to match the pattern, and enters the body if the
339 match was successful. If the match is irrefutable (when it cannot fail to
340 match), use a regular `let`-binding instead. For instance:
341
342 ```compile_fail,E0162
343 struct Irrefutable(i32);
344 let irr = Irrefutable(0);
345
346 // This fails to compile because the match is irrefutable.
347 if let Irrefutable(x) = irr {
348     // This body will always be executed.
349     // ...
350 }
351 ```
352
353 Try this instead:
354
355 ```
356 struct Irrefutable(i32);
357 let irr = Irrefutable(0);
358
359 let Irrefutable(x) = irr;
360 println!("{}", x);
361 ```
362 "##,
363
364 E0165: r##"
365 A while-let pattern attempts to match the pattern, and enters the body if the
366 match was successful. If the match is irrefutable (when it cannot fail to
367 match), use a regular `let`-binding inside a `loop` instead. For instance:
368
369 ```compile_fail,E0165
370 struct Irrefutable(i32);
371 let irr = Irrefutable(0);
372
373 // This fails to compile because the match is irrefutable.
374 while let Irrefutable(x) = irr {
375     // ...
376 }
377 ```
378
379 Try this instead:
380
381 ```no_run
382 struct Irrefutable(i32);
383 let irr = Irrefutable(0);
384
385 loop {
386     let Irrefutable(x) = irr;
387     // ...
388 }
389 ```
390 "##,
391
392 E0170: r##"
393 Enum variants are qualified by default. For example, given this type:
394
395 ```
396 enum Method {
397     GET,
398     POST,
399 }
400 ```
401
402 You would match it using:
403
404 ```
405 enum Method {
406     GET,
407     POST,
408 }
409
410 let m = Method::GET;
411
412 match m {
413     Method::GET => {},
414     Method::POST => {},
415 }
416 ```
417
418 If you don't qualify the names, the code will bind new variables named "GET" and
419 "POST" instead. This behavior is likely not what you want, so `rustc` warns when
420 that happens.
421
422 Qualified names are good practice, and most code works well with them. But if
423 you prefer them unqualified, you can import the variants into scope:
424
425 ```
426 use Method::*;
427 enum Method { GET, POST }
428 # fn main() {}
429 ```
430
431 If you want others to be able to import variants from your module directly, use
432 `pub use`:
433
434 ```
435 pub use Method::*;
436 pub enum Method { GET, POST }
437 # fn main() {}
438 ```
439 "##,
440
441
442 E0297: r##"
443 #### Note: this error code is no longer emitted by the compiler.
444
445 Patterns used to bind names must be irrefutable. That is, they must guarantee
446 that a name will be extracted in all cases. Instead of pattern matching the
447 loop variable, consider using a `match` or `if let` inside the loop body. For
448 instance:
449
450 ```compile_fail,E0005
451 let xs : Vec<Option<i32>> = vec![Some(1), None];
452
453 // This fails because `None` is not covered.
454 for Some(x) in xs {
455     // ...
456 }
457 ```
458
459 Match inside the loop instead:
460
461 ```
462 let xs : Vec<Option<i32>> = vec![Some(1), None];
463
464 for item in xs {
465     match item {
466         Some(x) => {},
467         None => {},
468     }
469 }
470 ```
471
472 Or use `if let`:
473
474 ```
475 let xs : Vec<Option<i32>> = vec![Some(1), None];
476
477 for item in xs {
478     if let Some(x) = item {
479         // ...
480     }
481 }
482 ```
483 "##,
484
485 E0301: r##"
486 Mutable borrows are not allowed in pattern guards, because matching cannot have
487 side effects. Side effects could alter the matched object or the environment
488 on which the match depends in such a way, that the match would not be
489 exhaustive. For instance, the following would not match any arm if mutable
490 borrows were allowed:
491
492 ```compile_fail,E0301
493 match Some(()) {
494     None => { },
495     option if option.take().is_none() => {
496         /* impossible, option is `Some` */
497     },
498     Some(_) => { } // When the previous match failed, the option became `None`.
499 }
500 ```
501 "##,
502
503 E0302: r##"
504 Assignments are not allowed in pattern guards, because matching cannot have
505 side effects. Side effects could alter the matched object or the environment
506 on which the match depends in such a way, that the match would not be
507 exhaustive. For instance, the following would not match any arm if assignments
508 were allowed:
509
510 ```compile_fail,E0302
511 match Some(()) {
512     None => { },
513     option if { option = None; false } => { },
514     Some(_) => { } // When the previous match failed, the option became `None`.
515 }
516 ```
517 "##,
518
519 E0303: r##"
520 In certain cases it is possible for sub-bindings to violate memory safety.
521 Updates to the borrow checker in a future version of Rust may remove this
522 restriction, but for now patterns must be rewritten without sub-bindings.
523
524 Before:
525
526 ```compile_fail,E0303
527 match Some("hi".to_string()) {
528     ref op_string_ref @ Some(s) => {},
529     None => {},
530 }
531 ```
532
533 After:
534
535 ```
536 match Some("hi".to_string()) {
537     Some(ref s) => {
538         let op_string_ref = &Some(s);
539         // ...
540     },
541     None => {},
542 }
543 ```
544
545 The `op_string_ref` binding has type `&Option<&String>` in both cases.
546
547 See also https://github.com/rust-lang/rust/issues/14587
548 "##,
549
550 E0010: r##"
551 The value of statics and constants must be known at compile time, and they live
552 for the entire lifetime of a program. Creating a boxed value allocates memory on
553 the heap at runtime, and therefore cannot be done at compile time. Erroneous
554 code example:
555
556 ```compile_fail,E0010
557 #![feature(box_syntax)]
558
559 const CON : Box<i32> = box 0;
560 ```
561 "##,
562
563 E0013: r##"
564 Static and const variables can refer to other const variables. But a const
565 variable cannot refer to a static variable. For example, `Y` cannot refer to
566 `X` here:
567
568 ```compile_fail,E0013
569 static X: i32 = 42;
570 const Y: i32 = X;
571 ```
572
573 To fix this, the value can be extracted as a const and then used:
574
575 ```
576 const A: i32 = 42;
577 static X: i32 = A;
578 const Y: i32 = A;
579 ```
580 "##,
581
582 // FIXME(#24111) Change the language here when const fn stabilizes
583 E0015: r##"
584 The only functions that can be called in static or constant expressions are
585 `const` functions, and struct/enum constructors. `const` functions are only
586 available on a nightly compiler. Rust currently does not support more general
587 compile-time function execution.
588
589 ```
590 const FOO: Option<u8> = Some(1); // enum constructor
591 struct Bar {x: u8}
592 const BAR: Bar = Bar {x: 1}; // struct constructor
593 ```
594
595 See [RFC 911] for more details on the design of `const fn`s.
596
597 [RFC 911]: https://github.com/rust-lang/rfcs/blob/master/text/0911-const-fn.md
598 "##,
599
600 E0017: r##"
601 References in statics and constants may only refer to immutable values.
602 Erroneous code example:
603
604 ```compile_fail,E0017
605 static X: i32 = 1;
606 const C: i32 = 2;
607
608 // these three are not allowed:
609 const CR: &'static mut i32 = &mut C;
610 static STATIC_REF: &'static mut i32 = &mut X;
611 static CONST_REF: &'static mut i32 = &mut C;
612 ```
613
614 Statics are shared everywhere, and if they refer to mutable data one might
615 violate memory safety since holding multiple mutable references to shared data
616 is not allowed.
617
618 If you really want global mutable state, try using `static mut` or a global
619 `UnsafeCell`.
620 "##,
621
622 E0019: r##"
623 A function call isn't allowed in the const's initialization expression
624 because the expression's value must be known at compile-time. Erroneous code
625 example:
626
627 ```compile_fail
628 enum Test {
629     V1
630 }
631
632 impl Test {
633     fn test(&self) -> i32 {
634         12
635     }
636 }
637
638 fn main() {
639     const FOO: Test = Test::V1;
640
641     const A: i32 = FOO.test(); // You can't call Test::func() here!
642 }
643 ```
644
645 Remember: you can't use a function call inside a const's initialization
646 expression! However, you can totally use it anywhere else:
647
648 ```
649 enum Test {
650     V1
651 }
652
653 impl Test {
654     fn func(&self) -> i32 {
655         12
656     }
657 }
658
659 fn main() {
660     const FOO: Test = Test::V1;
661
662     FOO.func(); // here is good
663     let x = FOO.func(); // or even here!
664 }
665 ```
666 "##,
667
668 E0022: r##"
669 Constant functions are not allowed to mutate anything. Thus, binding to an
670 argument with a mutable pattern is not allowed. For example,
671
672 ```compile_fail
673 const fn foo(mut x: u8) {
674     // do stuff
675 }
676 ```
677
678 Is incorrect because the function body may not mutate `x`.
679
680 Remove any mutable bindings from the argument list to fix this error. In case
681 you need to mutate the argument, try lazily initializing a global variable
682 instead of using a `const fn`, or refactoring the code to a functional style to
683 avoid mutation if possible.
684 "##,
685
686 E0133: r##"
687 Unsafe code was used outside of an unsafe function or block.
688
689 Erroneous code example:
690
691 ```compile_fail,E0133
692 unsafe fn f() { return; } // This is the unsafe code
693
694 fn main() {
695     f(); // error: call to unsafe function requires unsafe function or block
696 }
697 ```
698
699 Using unsafe functionality is potentially dangerous and disallowed by safety
700 checks. Examples:
701
702 * Dereferencing raw pointers
703 * Calling functions via FFI
704 * Calling functions marked unsafe
705
706 These safety checks can be relaxed for a section of the code by wrapping the
707 unsafe instructions with an `unsafe` block. For instance:
708
709 ```
710 unsafe fn f() { return; }
711
712 fn main() {
713     unsafe { f(); } // ok!
714 }
715 ```
716
717 See also https://doc.rust-lang.org/book/first-edition/unsafe.html
718 "##,
719
720 E0373: r##"
721 This error occurs when an attempt is made to use data captured by a closure,
722 when that data may no longer exist. It's most commonly seen when attempting to
723 return a closure:
724
725 ```compile_fail,E0373
726 fn foo() -> Box<Fn(u32) -> u32> {
727     let x = 0u32;
728     Box::new(|y| x + y)
729 }
730 ```
731
732 Notice that `x` is stack-allocated by `foo()`. By default, Rust captures
733 closed-over data by reference. This means that once `foo()` returns, `x` no
734 longer exists. An attempt to access `x` within the closure would thus be
735 unsafe.
736
737 Another situation where this might be encountered is when spawning threads:
738
739 ```compile_fail,E0373
740 fn foo() {
741     let x = 0u32;
742     let y = 1u32;
743
744     let thr = std::thread::spawn(|| {
745         x + y
746     });
747 }
748 ```
749
750 Since our new thread runs in parallel, the stack frame containing `x` and `y`
751 may well have disappeared by the time we try to use them. Even if we call
752 `thr.join()` within foo (which blocks until `thr` has completed, ensuring the
753 stack frame won't disappear), we will not succeed: the compiler cannot prove
754 that this behaviour is safe, and so won't let us do it.
755
756 The solution to this problem is usually to switch to using a `move` closure.
757 This approach moves (or copies, where possible) data into the closure, rather
758 than taking references to it. For example:
759
760 ```
761 fn foo() -> Box<Fn(u32) -> u32> {
762     let x = 0u32;
763     Box::new(move |y| x + y)
764 }
765 ```
766
767 Now that the closure has its own copy of the data, there's no need to worry
768 about safety.
769 "##,
770
771 E0381: r##"
772 It is not allowed to use or capture an uninitialized variable. For example:
773
774 ```compile_fail,E0381
775 fn main() {
776     let x: i32;
777     let y = x; // error, use of possibly uninitialized variable
778 }
779 ```
780
781 To fix this, ensure that any declared variables are initialized before being
782 used. Example:
783
784 ```
785 fn main() {
786     let x: i32 = 0;
787     let y = x; // ok!
788 }
789 ```
790 "##,
791
792 E0382: r##"
793 This error occurs when an attempt is made to use a variable after its contents
794 have been moved elsewhere. For example:
795
796 ```compile_fail,E0382
797 struct MyStruct { s: u32 }
798
799 fn main() {
800     let mut x = MyStruct{ s: 5u32 };
801     let y = x;
802     x.s = 6;
803     println!("{}", x.s);
804 }
805 ```
806
807 Since `MyStruct` is a type that is not marked `Copy`, the data gets moved out
808 of `x` when we set `y`. This is fundamental to Rust's ownership system: outside
809 of workarounds like `Rc`, a value cannot be owned by more than one variable.
810
811 Sometimes we don't need to move the value. Using a reference, we can let another
812 function borrow the value without changing its ownership. In the example below,
813 we don't actually have to move our string to `calculate_length`, we can give it
814 a reference to it with `&` instead.
815
816 ```
817 fn main() {
818     let s1 = String::from("hello");
819
820     let len = calculate_length(&s1);
821
822     println!("The length of '{}' is {}.", s1, len);
823 }
824
825 fn calculate_length(s: &String) -> usize {
826     s.len()
827 }
828 ```
829
830 A mutable reference can be created with `&mut`.
831
832 Sometimes we don't want a reference, but a duplicate. All types marked `Clone`
833 can be duplicated by calling `.clone()`. Subsequent changes to a clone do not
834 affect the original variable.
835
836 Most types in the standard library are marked `Clone`. The example below
837 demonstrates using `clone()` on a string. `s1` is first set to "many", and then
838 copied to `s2`. Then the first character of `s1` is removed, without affecting
839 `s2`. "any many" is printed to the console.
840
841 ```
842 fn main() {
843     let mut s1 = String::from("many");
844     let s2 = s1.clone();
845     s1.remove(0);
846     println!("{} {}", s1, s2);
847 }
848 ```
849
850 If we control the definition of a type, we can implement `Clone` on it ourselves
851 with `#[derive(Clone)]`.
852
853 Some types have no ownership semantics at all and are trivial to duplicate. An
854 example is `i32` and the other number types. We don't have to call `.clone()` to
855 clone them, because they are marked `Copy` in addition to `Clone`.  Implicit
856 cloning is more convenient in this case. We can mark our own types `Copy` if
857 all their members also are marked `Copy`.
858
859 In the example below, we implement a `Point` type. Because it only stores two
860 integers, we opt-out of ownership semantics with `Copy`. Then we can
861 `let p2 = p1` without `p1` being moved.
862
863 ```
864 #[derive(Copy, Clone)]
865 struct Point { x: i32, y: i32 }
866
867 fn main() {
868     let mut p1 = Point{ x: -1, y: 2 };
869     let p2 = p1;
870     p1.x = 1;
871     println!("p1: {}, {}", p1.x, p1.y);
872     println!("p2: {}, {}", p2.x, p2.y);
873 }
874 ```
875
876 Alternatively, if we don't control the struct's definition, or mutable shared
877 ownership is truly required, we can use `Rc` and `RefCell`:
878
879 ```
880 use std::cell::RefCell;
881 use std::rc::Rc;
882
883 struct MyStruct { s: u32 }
884
885 fn main() {
886     let mut x = Rc::new(RefCell::new(MyStruct{ s: 5u32 }));
887     let y = x.clone();
888     x.borrow_mut().s = 6;
889     println!("{}", x.borrow().s);
890 }
891 ```
892
893 With this approach, x and y share ownership of the data via the `Rc` (reference
894 count type). `RefCell` essentially performs runtime borrow checking: ensuring
895 that at most one writer or multiple readers can access the data at any one time.
896
897 If you wish to learn more about ownership in Rust, start with the chapter in the
898 Book:
899
900 https://doc.rust-lang.org/book/first-edition/ownership.html
901 "##,
902
903 E0383: r##"
904 This error occurs when an attempt is made to partially reinitialize a
905 structure that is currently uninitialized.
906
907 For example, this can happen when a drop has taken place:
908
909 ```compile_fail,E0383
910 struct Foo {
911     a: u32,
912 }
913 impl Drop for Foo {
914     fn drop(&mut self) { /* ... */ }
915 }
916
917 let mut x = Foo { a: 1 };
918 drop(x); // `x` is now uninitialized
919 x.a = 2; // error, partial reinitialization of uninitialized structure `t`
920 ```
921
922 This error can be fixed by fully reinitializing the structure in question:
923
924 ```
925 struct Foo {
926     a: u32,
927 }
928 impl Drop for Foo {
929     fn drop(&mut self) { /* ... */ }
930 }
931
932 let mut x = Foo { a: 1 };
933 drop(x);
934 x = Foo { a: 2 };
935 ```
936 "##,
937
938 E0384: r##"
939 This error occurs when an attempt is made to reassign an immutable variable.
940 For example:
941
942 ```compile_fail,E0384
943 fn main() {
944     let x = 3;
945     x = 5; // error, reassignment of immutable variable
946 }
947 ```
948
949 By default, variables in Rust are immutable. To fix this error, add the keyword
950 `mut` after the keyword `let` when declaring the variable. For example:
951
952 ```
953 fn main() {
954     let mut x = 3;
955     x = 5;
956 }
957 ```
958 "##,
959
960 /*E0386: r##"
961 This error occurs when an attempt is made to mutate the target of a mutable
962 reference stored inside an immutable container.
963
964 For example, this can happen when storing a `&mut` inside an immutable `Box`:
965
966 ```compile_fail,E0386
967 let mut x: i64 = 1;
968 let y: Box<_> = Box::new(&mut x);
969 **y = 2; // error, cannot assign to data in an immutable container
970 ```
971
972 This error can be fixed by making the container mutable:
973
974 ```
975 let mut x: i64 = 1;
976 let mut y: Box<_> = Box::new(&mut x);
977 **y = 2;
978 ```
979
980 It can also be fixed by using a type with interior mutability, such as `Cell`
981 or `RefCell`:
982
983 ```
984 use std::cell::Cell;
985
986 let x: i64 = 1;
987 let y: Box<Cell<_>> = Box::new(Cell::new(x));
988 y.set(2);
989 ```
990 "##,*/
991
992 E0387: r##"
993 This error occurs when an attempt is made to mutate or mutably reference data
994 that a closure has captured immutably. Examples of this error are shown below:
995
996 ```compile_fail,E0387
997 // Accepts a function or a closure that captures its environment immutably.
998 // Closures passed to foo will not be able to mutate their closed-over state.
999 fn foo<F: Fn()>(f: F) { }
1000
1001 // Attempts to mutate closed-over data. Error message reads:
1002 // `cannot assign to data in a captured outer variable...`
1003 fn mutable() {
1004     let mut x = 0u32;
1005     foo(|| x = 2);
1006 }
1007
1008 // Attempts to take a mutable reference to closed-over data.  Error message
1009 // reads: `cannot borrow data mutably in a captured outer variable...`
1010 fn mut_addr() {
1011     let mut x = 0u32;
1012     foo(|| { let y = &mut x; });
1013 }
1014 ```
1015
1016 The problem here is that foo is defined as accepting a parameter of type `Fn`.
1017 Closures passed into foo will thus be inferred to be of type `Fn`, meaning that
1018 they capture their context immutably.
1019
1020 If the definition of `foo` is under your control, the simplest solution is to
1021 capture the data mutably. This can be done by defining `foo` to take FnMut
1022 rather than Fn:
1023
1024 ```
1025 fn foo<F: FnMut()>(f: F) { }
1026 ```
1027
1028 Alternatively, we can consider using the `Cell` and `RefCell` types to achieve
1029 interior mutability through a shared reference. Our example's `mutable`
1030 function could be redefined as below:
1031
1032 ```
1033 use std::cell::Cell;
1034
1035 fn foo<F: Fn()>(f: F) { }
1036
1037 fn mutable() {
1038     let x = Cell::new(0u32);
1039     foo(|| x.set(2));
1040 }
1041 ```
1042
1043 You can read more about cell types in the API documentation:
1044
1045 https://doc.rust-lang.org/std/cell/
1046 "##,
1047
1048 E0388: r##"
1049 E0388 was removed and is no longer issued.
1050 "##,
1051
1052 E0389: r##"
1053 An attempt was made to mutate data using a non-mutable reference. This
1054 commonly occurs when attempting to assign to a non-mutable reference of a
1055 mutable reference (`&(&mut T)`).
1056
1057 Example of erroneous code:
1058
1059 ```compile_fail,E0389
1060 struct FancyNum {
1061     num: u8,
1062 }
1063
1064 fn main() {
1065     let mut fancy = FancyNum{ num: 5 };
1066     let fancy_ref = &(&mut fancy);
1067     fancy_ref.num = 6; // error: cannot assign to data in a `&` reference
1068     println!("{}", fancy_ref.num);
1069 }
1070 ```
1071
1072 Here, `&mut fancy` is mutable, but `&(&mut fancy)` is not. Creating an
1073 immutable reference to a value borrows it immutably. There can be multiple
1074 references of type `&(&mut T)` that point to the same value, so they must be
1075 immutable to prevent multiple mutable references to the same value.
1076
1077 To fix this, either remove the outer reference:
1078
1079 ```
1080 struct FancyNum {
1081     num: u8,
1082 }
1083
1084 fn main() {
1085     let mut fancy = FancyNum{ num: 5 };
1086
1087     let fancy_ref = &mut fancy;
1088     // `fancy_ref` is now &mut FancyNum, rather than &(&mut FancyNum)
1089
1090     fancy_ref.num = 6; // No error!
1091
1092     println!("{}", fancy_ref.num);
1093 }
1094 ```
1095
1096 Or make the outer reference mutable:
1097
1098 ```
1099 struct FancyNum {
1100     num: u8
1101 }
1102
1103 fn main() {
1104     let mut fancy = FancyNum{ num: 5 };
1105
1106     let fancy_ref = &mut (&mut fancy);
1107     // `fancy_ref` is now &mut(&mut FancyNum), rather than &(&mut FancyNum)
1108
1109     fancy_ref.num = 6; // No error!
1110
1111     println!("{}", fancy_ref.num);
1112 }
1113 ```
1114 "##,
1115
1116 E0161: r##"
1117 A value was moved. However, its size was not known at compile time, and only
1118 values of a known size can be moved.
1119
1120 Erroneous code example:
1121
1122 ```compile_fail
1123 #![feature(box_syntax)]
1124
1125 fn main() {
1126     let array: &[isize] = &[1, 2, 3];
1127     let _x: Box<[isize]> = box *array;
1128     // error: cannot move a value of type [isize]: the size of [isize] cannot
1129     //        be statically determined
1130 }
1131 ```
1132
1133 In Rust, you can only move a value when its size is known at compile time.
1134
1135 To work around this restriction, consider "hiding" the value behind a reference:
1136 either `&x` or `&mut x`. Since a reference has a fixed size, this lets you move
1137 it around as usual. Example:
1138
1139 ```
1140 #![feature(box_syntax)]
1141
1142 fn main() {
1143     let array: &[isize] = &[1, 2, 3];
1144     let _x: Box<&[isize]> = box array; // ok!
1145 }
1146 ```
1147 "##,
1148
1149 E0492: r##"
1150 A borrow of a constant containing interior mutability was attempted. Erroneous
1151 code example:
1152
1153 ```compile_fail,E0492
1154 use std::sync::atomic::{AtomicUsize, ATOMIC_USIZE_INIT};
1155
1156 const A: AtomicUsize = ATOMIC_USIZE_INIT;
1157 static B: &'static AtomicUsize = &A;
1158 // error: cannot borrow a constant which may contain interior mutability,
1159 //        create a static instead
1160 ```
1161
1162 A `const` represents a constant value that should never change. If one takes
1163 a `&` reference to the constant, then one is taking a pointer to some memory
1164 location containing the value. Normally this is perfectly fine: most values
1165 can't be changed via a shared `&` pointer, but interior mutability would allow
1166 it. That is, a constant value could be mutated. On the other hand, a `static` is
1167 explicitly a single memory location, which can be mutated at will.
1168
1169 So, in order to solve this error, either use statics which are `Sync`:
1170
1171 ```
1172 use std::sync::atomic::{AtomicUsize, ATOMIC_USIZE_INIT};
1173
1174 static A: AtomicUsize = ATOMIC_USIZE_INIT;
1175 static B: &'static AtomicUsize = &A; // ok!
1176 ```
1177
1178 You can also have this error while using a cell type:
1179
1180 ```compile_fail,E0492
1181 use std::cell::Cell;
1182
1183 const A: Cell<usize> = Cell::new(1);
1184 const B: &'static Cell<usize> = &A;
1185 // error: cannot borrow a constant which may contain interior mutability,
1186 //        create a static instead
1187
1188 // or:
1189 struct C { a: Cell<usize> }
1190
1191 const D: C = C { a: Cell::new(1) };
1192 const E: &'static Cell<usize> = &D.a; // error
1193
1194 // or:
1195 const F: &'static C = &D; // error
1196 ```
1197
1198 This is because cell types do operations that are not thread-safe. Due to this,
1199 they don't implement Sync and thus can't be placed in statics.
1200
1201 However, if you still wish to use these types, you can achieve this by an unsafe
1202 wrapper:
1203
1204 ```
1205 use std::cell::Cell;
1206 use std::marker::Sync;
1207
1208 struct NotThreadSafe<T> {
1209     value: Cell<T>,
1210 }
1211
1212 unsafe impl<T> Sync for NotThreadSafe<T> {}
1213
1214 static A: NotThreadSafe<usize> = NotThreadSafe { value : Cell::new(1) };
1215 static B: &'static NotThreadSafe<usize> = &A; // ok!
1216 ```
1217
1218 Remember this solution is unsafe! You will have to ensure that accesses to the
1219 cell are synchronized.
1220 "##,
1221
1222 E0499: r##"
1223 A variable was borrowed as mutable more than once. Erroneous code example:
1224
1225 ```compile_fail,E0499
1226 let mut i = 0;
1227 let mut x = &mut i;
1228 let mut a = &mut i;
1229 // error: cannot borrow `i` as mutable more than once at a time
1230 ```
1231
1232 Please note that in rust, you can either have many immutable references, or one
1233 mutable reference. Take a look at
1234 https://doc.rust-lang.org/stable/book/references-and-borrowing.html for more
1235 information. Example:
1236
1237
1238 ```
1239 let mut i = 0;
1240 let mut x = &mut i; // ok!
1241
1242 // or:
1243 let mut i = 0;
1244 let a = &i; // ok!
1245 let b = &i; // still ok!
1246 let c = &i; // still ok!
1247 ```
1248 "##,
1249
1250 E0500: r##"
1251 A borrowed variable was used in another closure. Example of erroneous code:
1252
1253 ```compile_fail
1254 fn you_know_nothing(jon_snow: &mut i32) {
1255     let nights_watch = || {
1256         *jon_snow = 2;
1257     };
1258     let starks = || {
1259         *jon_snow = 3; // error: closure requires unique access to `jon_snow`
1260                        //        but it is already borrowed
1261     };
1262 }
1263 ```
1264
1265 In here, `jon_snow` is already borrowed by the `nights_watch` closure, so it
1266 cannot be borrowed by the `starks` closure at the same time. To fix this issue,
1267 you can put the closure in its own scope:
1268
1269 ```
1270 fn you_know_nothing(jon_snow: &mut i32) {
1271     {
1272         let nights_watch = || {
1273             *jon_snow = 2;
1274         };
1275     } // At this point, `jon_snow` is free.
1276     let starks = || {
1277         *jon_snow = 3;
1278     };
1279 }
1280 ```
1281
1282 Or, if the type implements the `Clone` trait, you can clone it between
1283 closures:
1284
1285 ```
1286 fn you_know_nothing(jon_snow: &mut i32) {
1287     let mut jon_copy = jon_snow.clone();
1288     let nights_watch = || {
1289         jon_copy = 2;
1290     };
1291     let starks = || {
1292         *jon_snow = 3;
1293     };
1294 }
1295 ```
1296 "##,
1297
1298 E0501: r##"
1299 This error indicates that a mutable variable is being used while it is still
1300 captured by a closure. Because the closure has borrowed the variable, it is not
1301 available for use until the closure goes out of scope.
1302
1303 Note that a capture will either move or borrow a variable, but in this
1304 situation, the closure is borrowing the variable. Take a look at
1305 http://rustbyexample.com/fn/closures/capture.html for more information about
1306 capturing.
1307
1308 Example of erroneous code:
1309
1310 ```compile_fail,E0501
1311 fn inside_closure(x: &mut i32) {
1312     // Actions which require unique access
1313 }
1314
1315 fn outside_closure(x: &mut i32) {
1316     // Actions which require unique access
1317 }
1318
1319 fn foo(a: &mut i32) {
1320     let bar = || {
1321         inside_closure(a)
1322     };
1323     outside_closure(a); // error: cannot borrow `*a` as mutable because previous
1324                         //        closure requires unique access.
1325 }
1326 ```
1327
1328 To fix this error, you can place the closure in its own scope:
1329
1330 ```
1331 fn inside_closure(x: &mut i32) {}
1332 fn outside_closure(x: &mut i32) {}
1333
1334 fn foo(a: &mut i32) {
1335     {
1336         let bar = || {
1337             inside_closure(a)
1338         };
1339     } // borrow on `a` ends.
1340     outside_closure(a); // ok!
1341 }
1342 ```
1343
1344 Or you can pass the variable as a parameter to the closure:
1345
1346 ```
1347 fn inside_closure(x: &mut i32) {}
1348 fn outside_closure(x: &mut i32) {}
1349
1350 fn foo(a: &mut i32) {
1351     let bar = |s: &mut i32| {
1352         inside_closure(s)
1353     };
1354     outside_closure(a);
1355     bar(a);
1356 }
1357 ```
1358
1359 It may be possible to define the closure later:
1360
1361 ```
1362 fn inside_closure(x: &mut i32) {}
1363 fn outside_closure(x: &mut i32) {}
1364
1365 fn foo(a: &mut i32) {
1366     outside_closure(a);
1367     let bar = || {
1368         inside_closure(a)
1369     };
1370 }
1371 ```
1372 "##,
1373
1374 E0502: r##"
1375 This error indicates that you are trying to borrow a variable as mutable when it
1376 has already been borrowed as immutable.
1377
1378 Example of erroneous code:
1379
1380 ```compile_fail,E0502
1381 fn bar(x: &mut i32) {}
1382 fn foo(a: &mut i32) {
1383     let ref y = a; // a is borrowed as immutable.
1384     bar(a); // error: cannot borrow `*a` as mutable because `a` is also borrowed
1385             //        as immutable
1386 }
1387 ```
1388
1389 To fix this error, ensure that you don't have any other references to the
1390 variable before trying to access it mutably:
1391
1392 ```
1393 fn bar(x: &mut i32) {}
1394 fn foo(a: &mut i32) {
1395     bar(a);
1396     let ref y = a; // ok!
1397 }
1398 ```
1399
1400 For more information on the rust ownership system, take a look at
1401 https://doc.rust-lang.org/stable/book/references-and-borrowing.html.
1402 "##,
1403
1404 E0503: r##"
1405 A value was used after it was mutably borrowed.
1406
1407 Example of erroneous code:
1408
1409 ```compile_fail,E0503
1410 fn main() {
1411     let mut value = 3;
1412     // Create a mutable borrow of `value`. This borrow
1413     // lives until the end of this function.
1414     let _borrow = &mut value;
1415     let _sum = value + 1; // error: cannot use `value` because
1416                           //        it was mutably borrowed
1417 }
1418 ```
1419
1420 In this example, `value` is mutably borrowed by `borrow` and cannot be
1421 used to calculate `sum`. This is not possible because this would violate
1422 Rust's mutability rules.
1423
1424 You can fix this error by limiting the scope of the borrow:
1425
1426 ```
1427 fn main() {
1428     let mut value = 3;
1429     // By creating a new block, you can limit the scope
1430     // of the reference.
1431     {
1432         let _borrow = &mut value; // Use `_borrow` inside this block.
1433     }
1434     // The block has ended and with it the borrow.
1435     // You can now use `value` again.
1436     let _sum = value + 1;
1437 }
1438 ```
1439
1440 Or by cloning `value` before borrowing it:
1441
1442 ```
1443 fn main() {
1444     let mut value = 3;
1445     // We clone `value`, creating a copy.
1446     let value_cloned = value.clone();
1447     // The mutable borrow is a reference to `value` and
1448     // not to `value_cloned`...
1449     let _borrow = &mut value;
1450     // ... which means we can still use `value_cloned`,
1451     let _sum = value_cloned + 1;
1452     // even though the borrow only ends here.
1453 }
1454 ```
1455
1456 You can find more information about borrowing in the rust-book:
1457 http://doc.rust-lang.org/stable/book/references-and-borrowing.html
1458 "##,
1459
1460 E0504: r##"
1461 This error occurs when an attempt is made to move a borrowed variable into a
1462 closure.
1463
1464 Example of erroneous code:
1465
1466 ```compile_fail,E0504
1467 struct FancyNum {
1468     num: u8,
1469 }
1470
1471 fn main() {
1472     let fancy_num = FancyNum { num: 5 };
1473     let fancy_ref = &fancy_num;
1474
1475     let x = move || {
1476         println!("child function: {}", fancy_num.num);
1477         // error: cannot move `fancy_num` into closure because it is borrowed
1478     };
1479
1480     x();
1481     println!("main function: {}", fancy_ref.num);
1482 }
1483 ```
1484
1485 Here, `fancy_num` is borrowed by `fancy_ref` and so cannot be moved into
1486 the closure `x`. There is no way to move a value into a closure while it is
1487 borrowed, as that would invalidate the borrow.
1488
1489 If the closure can't outlive the value being moved, try using a reference
1490 rather than moving:
1491
1492 ```
1493 struct FancyNum {
1494     num: u8,
1495 }
1496
1497 fn main() {
1498     let fancy_num = FancyNum { num: 5 };
1499     let fancy_ref = &fancy_num;
1500
1501     let x = move || {
1502         // fancy_ref is usable here because it doesn't move `fancy_num`
1503         println!("child function: {}", fancy_ref.num);
1504     };
1505
1506     x();
1507
1508     println!("main function: {}", fancy_num.num);
1509 }
1510 ```
1511
1512 If the value has to be borrowed and then moved, try limiting the lifetime of
1513 the borrow using a scoped block:
1514
1515 ```
1516 struct FancyNum {
1517     num: u8,
1518 }
1519
1520 fn main() {
1521     let fancy_num = FancyNum { num: 5 };
1522
1523     {
1524         let fancy_ref = &fancy_num;
1525         println!("main function: {}", fancy_ref.num);
1526         // `fancy_ref` goes out of scope here
1527     }
1528
1529     let x = move || {
1530         // `fancy_num` can be moved now (no more references exist)
1531         println!("child function: {}", fancy_num.num);
1532     };
1533
1534     x();
1535 }
1536 ```
1537
1538 If the lifetime of a reference isn't enough, such as in the case of threading,
1539 consider using an `Arc` to create a reference-counted value:
1540
1541 ```
1542 use std::sync::Arc;
1543 use std::thread;
1544
1545 struct FancyNum {
1546     num: u8,
1547 }
1548
1549 fn main() {
1550     let fancy_ref1 = Arc::new(FancyNum { num: 5 });
1551     let fancy_ref2 = fancy_ref1.clone();
1552
1553     let x = thread::spawn(move || {
1554         // `fancy_ref1` can be moved and has a `'static` lifetime
1555         println!("child thread: {}", fancy_ref1.num);
1556     });
1557
1558     x.join().expect("child thread should finish");
1559     println!("main thread: {}", fancy_ref2.num);
1560 }
1561 ```
1562 "##,
1563
1564 E0505: r##"
1565 A value was moved out while it was still borrowed.
1566
1567 Erroneous code example:
1568
1569 ```compile_fail,E0505
1570 struct Value {}
1571
1572 fn eat(val: Value) {}
1573
1574 fn main() {
1575     let x = Value{};
1576     {
1577         let _ref_to_val: &Value = &x;
1578         eat(x);
1579     }
1580 }
1581 ```
1582
1583 Here, the function `eat` takes the ownership of `x`. However,
1584 `x` cannot be moved because it was borrowed to `_ref_to_val`.
1585 To fix that you can do few different things:
1586
1587 * Try to avoid moving the variable.
1588 * Release borrow before move.
1589 * Implement the `Copy` trait on the type.
1590
1591 Examples:
1592
1593 ```
1594 struct Value {}
1595
1596 fn eat(val: &Value) {}
1597
1598 fn main() {
1599     let x = Value{};
1600     {
1601         let _ref_to_val: &Value = &x;
1602         eat(&x); // pass by reference, if it's possible
1603     }
1604 }
1605 ```
1606
1607 Or:
1608
1609 ```
1610 struct Value {}
1611
1612 fn eat(val: Value) {}
1613
1614 fn main() {
1615     let x = Value{};
1616     {
1617         let _ref_to_val: &Value = &x;
1618     }
1619     eat(x); // release borrow and then move it.
1620 }
1621 ```
1622
1623 Or:
1624
1625 ```
1626 #[derive(Clone, Copy)] // implement Copy trait
1627 struct Value {}
1628
1629 fn eat(val: Value) {}
1630
1631 fn main() {
1632     let x = Value{};
1633     {
1634         let _ref_to_val: &Value = &x;
1635         eat(x); // it will be copied here.
1636     }
1637 }
1638 ```
1639
1640 You can find more information about borrowing in the rust-book:
1641 http://doc.rust-lang.org/stable/book/references-and-borrowing.html
1642 "##,
1643
1644 E0506: r##"
1645 This error occurs when an attempt is made to assign to a borrowed value.
1646
1647 Example of erroneous code:
1648
1649 ```compile_fail,E0506
1650 struct FancyNum {
1651     num: u8,
1652 }
1653
1654 fn main() {
1655     let mut fancy_num = FancyNum { num: 5 };
1656     let fancy_ref = &fancy_num;
1657     fancy_num = FancyNum { num: 6 };
1658     // error: cannot assign to `fancy_num` because it is borrowed
1659
1660     println!("Num: {}, Ref: {}", fancy_num.num, fancy_ref.num);
1661 }
1662 ```
1663
1664 Because `fancy_ref` still holds a reference to `fancy_num`, `fancy_num` can't
1665 be assigned to a new value as it would invalidate the reference.
1666
1667 Alternatively, we can move out of `fancy_num` into a second `fancy_num`:
1668
1669 ```
1670 struct FancyNum {
1671     num: u8,
1672 }
1673
1674 fn main() {
1675     let mut fancy_num = FancyNum { num: 5 };
1676     let moved_num = fancy_num;
1677     fancy_num = FancyNum { num: 6 };
1678
1679     println!("Num: {}, Moved num: {}", fancy_num.num, moved_num.num);
1680 }
1681 ```
1682
1683 If the value has to be borrowed, try limiting the lifetime of the borrow using
1684 a scoped block:
1685
1686 ```
1687 struct FancyNum {
1688     num: u8,
1689 }
1690
1691 fn main() {
1692     let mut fancy_num = FancyNum { num: 5 };
1693
1694     {
1695         let fancy_ref = &fancy_num;
1696         println!("Ref: {}", fancy_ref.num);
1697     }
1698
1699     // Works because `fancy_ref` is no longer in scope
1700     fancy_num = FancyNum { num: 6 };
1701     println!("Num: {}", fancy_num.num);
1702 }
1703 ```
1704
1705 Or by moving the reference into a function:
1706
1707 ```
1708 struct FancyNum {
1709     num: u8,
1710 }
1711
1712 fn main() {
1713     let mut fancy_num = FancyNum { num: 5 };
1714
1715     print_fancy_ref(&fancy_num);
1716
1717     // Works because function borrow has ended
1718     fancy_num = FancyNum { num: 6 };
1719     println!("Num: {}", fancy_num.num);
1720 }
1721
1722 fn print_fancy_ref(fancy_ref: &FancyNum){
1723     println!("Ref: {}", fancy_ref.num);
1724 }
1725 ```
1726 "##,
1727
1728 E0507: r##"
1729 You tried to move out of a value which was borrowed. Erroneous code example:
1730
1731 ```compile_fail,E0507
1732 use std::cell::RefCell;
1733
1734 struct TheDarkKnight;
1735
1736 impl TheDarkKnight {
1737     fn nothing_is_true(self) {}
1738 }
1739
1740 fn main() {
1741     let x = RefCell::new(TheDarkKnight);
1742
1743     x.borrow().nothing_is_true(); // error: cannot move out of borrowed content
1744 }
1745 ```
1746
1747 Here, the `nothing_is_true` method takes the ownership of `self`. However,
1748 `self` cannot be moved because `.borrow()` only provides an `&TheDarkKnight`,
1749 which is a borrow of the content owned by the `RefCell`. To fix this error,
1750 you have three choices:
1751
1752 * Try to avoid moving the variable.
1753 * Somehow reclaim the ownership.
1754 * Implement the `Copy` trait on the type.
1755
1756 Examples:
1757
1758 ```
1759 use std::cell::RefCell;
1760
1761 struct TheDarkKnight;
1762
1763 impl TheDarkKnight {
1764     fn nothing_is_true(&self) {} // First case, we don't take ownership
1765 }
1766
1767 fn main() {
1768     let x = RefCell::new(TheDarkKnight);
1769
1770     x.borrow().nothing_is_true(); // ok!
1771 }
1772 ```
1773
1774 Or:
1775
1776 ```
1777 use std::cell::RefCell;
1778
1779 struct TheDarkKnight;
1780
1781 impl TheDarkKnight {
1782     fn nothing_is_true(self) {}
1783 }
1784
1785 fn main() {
1786     let x = RefCell::new(TheDarkKnight);
1787     let x = x.into_inner(); // we get back ownership
1788
1789     x.nothing_is_true(); // ok!
1790 }
1791 ```
1792
1793 Or:
1794
1795 ```
1796 use std::cell::RefCell;
1797
1798 #[derive(Clone, Copy)] // we implement the Copy trait
1799 struct TheDarkKnight;
1800
1801 impl TheDarkKnight {
1802     fn nothing_is_true(self) {}
1803 }
1804
1805 fn main() {
1806     let x = RefCell::new(TheDarkKnight);
1807
1808     x.borrow().nothing_is_true(); // ok!
1809 }
1810 ```
1811
1812 Moving a member out of a mutably borrowed struct will also cause E0507 error:
1813
1814 ```compile_fail,E0507
1815 struct TheDarkKnight;
1816
1817 impl TheDarkKnight {
1818     fn nothing_is_true(self) {}
1819 }
1820
1821 struct Batcave {
1822     knight: TheDarkKnight
1823 }
1824
1825 fn main() {
1826     let mut cave = Batcave {
1827         knight: TheDarkKnight
1828     };
1829     let borrowed = &mut cave;
1830
1831     borrowed.knight.nothing_is_true(); // E0507
1832 }
1833 ```
1834
1835 It is fine only if you put something back. `mem::replace` can be used for that:
1836
1837 ```
1838 # struct TheDarkKnight;
1839 # impl TheDarkKnight { fn nothing_is_true(self) {} }
1840 # struct Batcave { knight: TheDarkKnight }
1841 use std::mem;
1842
1843 let mut cave = Batcave {
1844     knight: TheDarkKnight
1845 };
1846 let borrowed = &mut cave;
1847
1848 mem::replace(&mut borrowed.knight, TheDarkKnight).nothing_is_true(); // ok!
1849 ```
1850
1851 You can find more information about borrowing in the rust-book:
1852 http://doc.rust-lang.org/book/first-edition/references-and-borrowing.html
1853 "##,
1854
1855 E0508: r##"
1856 A value was moved out of a non-copy fixed-size array.
1857
1858 Example of erroneous code:
1859
1860 ```compile_fail,E0508
1861 struct NonCopy;
1862
1863 fn main() {
1864     let array = [NonCopy; 1];
1865     let _value = array[0]; // error: cannot move out of type `[NonCopy; 1]`,
1866                            //        a non-copy fixed-size array
1867 }
1868 ```
1869
1870 The first element was moved out of the array, but this is not
1871 possible because `NonCopy` does not implement the `Copy` trait.
1872
1873 Consider borrowing the element instead of moving it:
1874
1875 ```
1876 struct NonCopy;
1877
1878 fn main() {
1879     let array = [NonCopy; 1];
1880     let _value = &array[0]; // Borrowing is allowed, unlike moving.
1881 }
1882 ```
1883
1884 Alternatively, if your type implements `Clone` and you need to own the value,
1885 consider borrowing and then cloning:
1886
1887 ```
1888 #[derive(Clone)]
1889 struct NonCopy;
1890
1891 fn main() {
1892     let array = [NonCopy; 1];
1893     // Now you can clone the array element.
1894     let _value = array[0].clone();
1895 }
1896 ```
1897 "##,
1898
1899 E0509: r##"
1900 This error occurs when an attempt is made to move out of a value whose type
1901 implements the `Drop` trait.
1902
1903 Example of erroneous code:
1904
1905 ```compile_fail,E0509
1906 struct FancyNum {
1907     num: usize
1908 }
1909
1910 struct DropStruct {
1911     fancy: FancyNum
1912 }
1913
1914 impl Drop for DropStruct {
1915     fn drop(&mut self) {
1916         // Destruct DropStruct, possibly using FancyNum
1917     }
1918 }
1919
1920 fn main() {
1921     let drop_struct = DropStruct{fancy: FancyNum{num: 5}};
1922     let fancy_field = drop_struct.fancy; // Error E0509
1923     println!("Fancy: {}", fancy_field.num);
1924     // implicit call to `drop_struct.drop()` as drop_struct goes out of scope
1925 }
1926 ```
1927
1928 Here, we tried to move a field out of a struct of type `DropStruct` which
1929 implements the `Drop` trait. However, a struct cannot be dropped if one or
1930 more of its fields have been moved.
1931
1932 Structs implementing the `Drop` trait have an implicit destructor that gets
1933 called when they go out of scope. This destructor may use the fields of the
1934 struct, so moving out of the struct could make it impossible to run the
1935 destructor. Therefore, we must think of all values whose type implements the
1936 `Drop` trait as single units whose fields cannot be moved.
1937
1938 This error can be fixed by creating a reference to the fields of a struct,
1939 enum, or tuple using the `ref` keyword:
1940
1941 ```
1942 struct FancyNum {
1943     num: usize
1944 }
1945
1946 struct DropStruct {
1947     fancy: FancyNum
1948 }
1949
1950 impl Drop for DropStruct {
1951     fn drop(&mut self) {
1952         // Destruct DropStruct, possibly using FancyNum
1953     }
1954 }
1955
1956 fn main() {
1957     let drop_struct = DropStruct{fancy: FancyNum{num: 5}};
1958     let ref fancy_field = drop_struct.fancy; // No more errors!
1959     println!("Fancy: {}", fancy_field.num);
1960     // implicit call to `drop_struct.drop()` as drop_struct goes out of scope
1961 }
1962 ```
1963
1964 Note that this technique can also be used in the arms of a match expression:
1965
1966 ```
1967 struct FancyNum {
1968     num: usize
1969 }
1970
1971 enum DropEnum {
1972     Fancy(FancyNum)
1973 }
1974
1975 impl Drop for DropEnum {
1976     fn drop(&mut self) {
1977         // Destruct DropEnum, possibly using FancyNum
1978     }
1979 }
1980
1981 fn main() {
1982     // Creates and enum of type `DropEnum`, which implements `Drop`
1983     let drop_enum = DropEnum::Fancy(FancyNum{num: 10});
1984     match drop_enum {
1985         // Creates a reference to the inside of `DropEnum::Fancy`
1986         DropEnum::Fancy(ref fancy_field) => // No error!
1987             println!("It was fancy-- {}!", fancy_field.num),
1988     }
1989     // implicit call to `drop_enum.drop()` as drop_enum goes out of scope
1990 }
1991 ```
1992 "##,
1993
1994 E0579: r##"
1995 When matching against an exclusive range, the compiler verifies that the range
1996 is non-empty. Exclusive range patterns include the start point but not the end
1997 point, so this is equivalent to requiring the start of the range to be less
1998 than the end of the range.
1999
2000 For example:
2001
2002 ```compile_fail
2003 match 5u32 {
2004     // This range is ok, albeit pointless.
2005     1 .. 2 => {}
2006     // This range is empty, and the compiler can tell.
2007     5 .. 5 => {}
2008 }
2009 ```
2010 "##,
2011
2012 E0595: r##"
2013 Closures cannot mutate immutable captured variables.
2014
2015 Erroneous code example:
2016
2017 ```compile_fail,E0595
2018 let x = 3; // error: closure cannot assign to immutable local variable `x`
2019 let mut c = || { x += 1 };
2020 ```
2021
2022 Make the variable binding mutable:
2023
2024 ```
2025 let mut x = 3; // ok!
2026 let mut c = || { x += 1 };
2027 ```
2028 "##,
2029
2030 E0596: r##"
2031 This error occurs because you tried to mutably borrow a non-mutable variable.
2032
2033 Example of erroneous code:
2034
2035 ```compile_fail,E0596
2036 let x = 1;
2037 let y = &mut x; // error: cannot borrow mutably
2038 ```
2039
2040 In here, `x` isn't mutable, so when we try to mutably borrow it in `y`, it
2041 fails. To fix this error, you need to make `x` mutable:
2042
2043 ```
2044 let mut x = 1;
2045 let y = &mut x; // ok!
2046 ```
2047 "##,
2048
2049 E0597: r##"
2050 This error occurs because a borrow was made inside a variable which has a
2051 greater lifetime than the borrowed one.
2052
2053 Example of erroneous code:
2054
2055 ```compile_fail,E0597
2056 struct Foo<'a> {
2057     x: Option<&'a u32>,
2058 }
2059
2060 let mut x = Foo { x: None };
2061 let y = 0;
2062 x.x = Some(&y); // error: `y` does not live long enough
2063 ```
2064
2065 In here, `x` is created before `y` and therefore has a greater lifetime. Always
2066 keep in mind that values in a scope are dropped in the opposite order they are
2067 created. So to fix the previous example, just make the `y` lifetime greater than
2068 the `x`'s one:
2069
2070 ```
2071 struct Foo<'a> {
2072     x: Option<&'a u32>,
2073 }
2074
2075 let y = 0;
2076 let mut x = Foo { x: None };
2077 x.x = Some(&y);
2078 ```
2079 "##,
2080
2081 E0626: r##"
2082 This error occurs because a borrow in a generator persists across a
2083 yield point.
2084
2085 ```compile_fail,E0626
2086 # #![feature(generators, generator_trait)]
2087 # use std::ops::Generator;
2088 let mut b = || {
2089     let a = &String::new(); // <-- This borrow...
2090     yield (); // ...is still in scope here, when the yield occurs.
2091     println!("{}", a);
2092 };
2093 unsafe { b.resume() };
2094 ```
2095
2096 At present, it is not permitted to have a yield that occurs while a
2097 borrow is still in scope. To resolve this error, the borrow must
2098 either be "contained" to a smaller scope that does not overlap the
2099 yield or else eliminated in another way. So, for example, we might
2100 resolve the previous example by removing the borrow and just storing
2101 the integer by value:
2102
2103 ```
2104 # #![feature(generators, generator_trait)]
2105 # use std::ops::Generator;
2106 let mut b = || {
2107     let a = 3;
2108     yield ();
2109     println!("{}", a);
2110 };
2111 unsafe { b.resume() };
2112 ```
2113
2114 This is a very simple case, of course. In more complex cases, we may
2115 wish to have more than one reference to the value that was borrowed --
2116 in those cases, something like the `Rc` or `Arc` types may be useful.
2117
2118 This error also frequently arises with iteration:
2119
2120 ```compile_fail,E0626
2121 # #![feature(generators, generator_trait)]
2122 # use std::ops::Generator;
2123 let mut b = || {
2124   let v = vec![1,2,3];
2125   for &x in &v { // <-- borrow of `v` is still in scope...
2126     yield x; // ...when this yield occurs.
2127   }
2128 };
2129 unsafe { b.resume() };
2130 ```
2131
2132 Such cases can sometimes be resolved by iterating "by value" (or using
2133 `into_iter()`) to avoid borrowing:
2134
2135 ```
2136 # #![feature(generators, generator_trait)]
2137 # use std::ops::Generator;
2138 let mut b = || {
2139   let v = vec![1,2,3];
2140   for x in v { // <-- Take ownership of the values instead!
2141     yield x; // <-- Now yield is OK.
2142   }
2143 };
2144 unsafe { b.resume() };
2145 ```
2146
2147 If taking ownership is not an option, using indices can work too:
2148
2149 ```
2150 # #![feature(generators, generator_trait)]
2151 # use std::ops::Generator;
2152 let mut b = || {
2153   let v = vec![1,2,3];
2154   let len = v.len(); // (*)
2155   for i in 0..len {
2156     let x = v[i]; // (*)
2157     yield x; // <-- Now yield is OK.
2158   }
2159 };
2160 unsafe { b.resume() };
2161
2162 // (*) -- Unfortunately, these temporaries are currently required.
2163 // See <https://github.com/rust-lang/rust/issues/43122>.
2164 ```
2165 "##,
2166
2167 E0712: r##"
2168 This error occurs because a borrow of a thread-local variable was made inside a
2169 function which outlived the lifetime of the function.
2170
2171 Example of erroneous code:
2172
2173 ```compile_fail,E0712
2174 #![feature(nll)]
2175 #![feature(thread_local)]
2176
2177 #[thread_local]
2178 static FOO: u8 = 3;
2179
2180 fn main() {
2181     let a = &FOO; // error: thread-local variable borrowed past end of function
2182
2183     std::thread::spawn(move || {
2184         println!("{}", a);
2185     });
2186 }
2187 ```
2188 "##,
2189
2190 E0713: r##"
2191 This error occurs when an attempt is made to borrow state past the end of the
2192 lifetime of a type that implements the `Drop` trait.
2193
2194 Example of erroneous code:
2195
2196 ```compile_fail,E0713
2197 #![feature(nll)]
2198
2199 pub struct S<'a> { data: &'a mut String }
2200
2201 impl<'a> Drop for S<'a> {
2202     fn drop(&mut self) { self.data.push_str("being dropped"); }
2203 }
2204
2205 fn demo<'a>(s: S<'a>) -> &'a mut String { let p = &mut *s.data; p }
2206 ```
2207
2208 Here, `demo` tries to borrow the string data held within its
2209 argument `s` and then return that borrow. However, `S` is
2210 declared as implementing `Drop`.
2211
2212 Structs implementing the `Drop` trait have an implicit destructor that
2213 gets called when they go out of scope. This destructor gets exclusive
2214 access to the fields of the struct when it runs.
2215
2216 This means that when `s` reaches the end of `demo`, its destructor
2217 gets exclusive access to its `&mut`-borrowed string data.  allowing
2218 another borrow of that string data (`p`), to exist across the drop of
2219 `s` would be a violation of the principle that `&mut`-borrows have
2220 exclusive, unaliased access to their referenced data.
2221
2222 This error can be fixed by changing `demo` so that the destructor does
2223 not run while the string-data is borrowed; for example by taking `S`
2224 by reference:
2225
2226 ```
2227 #![feature(nll)]
2228
2229 pub struct S<'a> { data: &'a mut String }
2230
2231 impl<'a> Drop for S<'a> {
2232     fn drop(&mut self) { self.data.push_str("being dropped"); }
2233 }
2234
2235 fn demo<'a>(s: &'a mut S<'a>) -> &'a mut String { let p = &mut *(*s).data; p }
2236 ```
2237
2238 Note that this approach needs a reference to S with lifetime `'a`.
2239 Nothing shorter than `'a` will suffice: a shorter lifetime would imply
2240 that after `demo` finishes excuting, something else (such as the
2241 destructor!) could access `s.data` after the end of that shorter
2242 lifetime, which would again violate the `&mut`-borrow's exclusive
2243 access.
2244
2245 "##,
2246
2247 }
2248
2249 register_diagnostics! {
2250 //  E0298, // cannot compare constants
2251 //  E0299, // mismatched types between arms
2252 //  E0471, // constant evaluation error (in pattern)
2253 //    E0385, // {} in an aliasable location
2254     E0493, // destructors cannot be evaluated at compile-time
2255     E0524, // two closures require unique access to `..` at the same time
2256     E0526, // shuffle indices are not constant
2257     E0594, // cannot assign to {}
2258     E0598, // lifetime of {} is too short to guarantee its contents can be...
2259     E0625, // thread-local statics cannot be accessed at compile-time
2260 }