1 #![allow(non_snake_case)]
3 register_long_diagnostics! {
7 #### Note: this error code is no longer emitted by the compiler.
9 This error suggests that the expression arm corresponding to the noted pattern
10 will never be reached as for all possible values of the expression being
11 matched, one of the preceding patterns will match.
13 This means that perhaps some of the preceding patterns are too general, this
14 one is too specific or the ordering is incorrect.
16 For example, the following `match` block has too many arms:
20 Some(bar) => {/* ... */}
21 x => {/* ... */} // This handles the `None` case
22 _ => {/* ... */} // All possible cases have already been handled
26 `match` blocks have their patterns matched in order, so, for example, putting
27 a wildcard arm above a more specific arm will make the latter arm irrelevant.
29 Ensure the ordering of the match arm is correct and remove any superfluous
34 #### Note: this error code is no longer emitted by the compiler.
36 This error indicates that an empty match expression is invalid because the type
37 it is matching on is non-empty (there exist values of this type). In safe code
38 it is impossible to create an instance of an empty type, so empty match
39 expressions are almost never desired. This error is typically fixed by adding
40 one or more cases to the match expression.
42 An example of an empty type is `enum Empty { }`. So, the following will work:
57 fn foo(x: Option<String>) {
66 This error indicates that the compiler cannot guarantee a matching pattern for
67 one or more possible inputs to a match expression. Guaranteed matches are
68 required in order to assign values to match expressions, or alternatively,
69 determine the flow of execution. Erroneous code example:
77 let x = Terminator::HastaLaVistaBaby;
79 match x { // error: non-exhaustive patterns: `HastaLaVistaBaby` not covered
80 Terminator::TalkToMyHand => {}
84 If you encounter this error you must alter your patterns so that every possible
85 value of the input type is matched. For types with a small number of variants
86 (like enums) you should probably cover all cases explicitly. Alternatively, the
87 underscore `_` wildcard pattern can be added after all other patterns to match
88 "anything else". Example:
96 let x = Terminator::HastaLaVistaBaby;
99 Terminator::TalkToMyHand => {}
100 Terminator::HastaLaVistaBaby => {}
106 Terminator::TalkToMyHand => {}
113 Patterns used to bind names must be irrefutable, that is, they must guarantee
114 that a name will be extracted in all cases. Erroneous code example:
116 ```compile_fail,E0005
119 // error: refutable pattern in local binding: `None` not covered
122 If you encounter this error you probably need to use a `match` or `if let` to
123 deal with the possibility of failure. Example:
144 This error indicates that the bindings in a match arm would require a value to
145 be moved into more than one location, thus violating unique ownership. Code
146 like the following is invalid as it requires the entire `Option<String>` to be
147 moved into a variable called `op_string` while simultaneously requiring the
148 inner `String` to be moved into a variable called `s`.
150 ```compile_fail,E0007
151 let x = Some("s".to_string());
154 op_string @ Some(s) => {}, // error: cannot bind by-move with sub-bindings
159 See also the error E0303.
163 Names bound in match arms retain their type in pattern guards. As such, if a
164 name is bound by move in a pattern, it should also be moved to wherever it is
165 referenced in the pattern guard code. Doing so however would prevent the name
166 from being available in the body of the match arm. Consider the following:
168 ```compile_fail,E0008
169 match Some("hi".to_string()) {
170 Some(s) if s.len() == 0 => {}, // use s.
175 The variable `s` has type `String`, and its use in the guard is as a variable of
176 type `String`. The guard code effectively executes in a separate scope to the
177 body of the arm, so the value would be moved into this anonymous scope and
178 therefore becomes unavailable in the body of the arm.
180 The problem above can be solved by using the `ref` keyword.
183 match Some("hi".to_string()) {
184 Some(ref s) if s.len() == 0 => {},
189 Though this example seems innocuous and easy to solve, the problem becomes clear
190 when it encounters functions which consume the value:
192 ```compile_fail,E0008
196 fn consume(self) -> usize {
204 Some(y) if y.consume() > 0 => {}
210 In this situation, even the `ref` keyword cannot solve it, since borrowed
211 content cannot be moved. This problem cannot be solved generally. If the value
212 can be cloned, here is a not-so-specific solution:
219 fn consume(self) -> usize {
227 Some(ref y) if y.clone().consume() > 0 => {}
233 If the value will be consumed in the pattern guard, using its clone will not
234 move its ownership, so the code works.
238 In a pattern, all values that don't implement the `Copy` trait have to be bound
239 the same way. The goal here is to avoid binding simultaneously by-move and
242 This limitation may be removed in a future version of Rust.
244 Erroneous code example:
246 ```compile_fail,E0009
249 let x = Some((X { x: () }, X { x: () }));
251 Some((y, ref z)) => {}, // error: cannot bind by-move and by-ref in the
257 You have two solutions:
259 Solution #1: Bind the pattern's values the same way.
264 let x = Some((X { x: () }, X { x: () }));
266 Some((ref y, ref z)) => {},
267 // or Some((y, z)) => {}
272 Solution #2: Implement the `Copy` trait for the `X` structure.
274 However, please keep in mind that the first solution should be preferred.
277 #[derive(Clone, Copy)]
280 let x = Some((X { x: () }, X { x: () }));
282 Some((y, ref z)) => {},
289 When matching against a range, the compiler verifies that the range is
290 non-empty. Range patterns include both end-points, so this is equivalent to
291 requiring the start of the range to be less than or equal to the end of the
298 // This range is ok, albeit pointless.
300 // This range is empty, and the compiler can tell.
307 `const` and `static` mean different things. A `const` is a compile-time
308 constant, an alias for a literal value. This property means you can match it
309 directly within a pattern.
311 The `static` keyword, on the other hand, guarantees a fixed location in memory.
312 This does not always mean that the value is constant. For example, a global
313 mutex can be declared `static` as well.
315 If you want to match against a `static`, consider using a guard instead:
318 static FORTY_TWO: i32 = 42;
321 Some(x) if x == FORTY_TWO => {}
328 An if-let pattern attempts to match the pattern, and enters the body if the
329 match was successful. If the match is irrefutable (when it cannot fail to
330 match), use a regular `let`-binding instead. For instance:
332 ```compile_fail,E0162
333 struct Irrefutable(i32);
334 let irr = Irrefutable(0);
336 // This fails to compile because the match is irrefutable.
337 if let Irrefutable(x) = irr {
338 // This body will always be executed.
346 struct Irrefutable(i32);
347 let irr = Irrefutable(0);
349 let Irrefutable(x) = irr;
355 A while-let pattern attempts to match the pattern, and enters the body if the
356 match was successful. If the match is irrefutable (when it cannot fail to
357 match), use a regular `let`-binding inside a `loop` instead. For instance:
359 ```compile_fail,E0165
360 struct Irrefutable(i32);
361 let irr = Irrefutable(0);
363 // This fails to compile because the match is irrefutable.
364 while let Irrefutable(x) = irr {
372 struct Irrefutable(i32);
373 let irr = Irrefutable(0);
376 let Irrefutable(x) = irr;
383 Enum variants are qualified by default. For example, given this type:
392 You would match it using:
408 If you don't qualify the names, the code will bind new variables named "GET" and
409 "POST" instead. This behavior is likely not what you want, so `rustc` warns when
412 Qualified names are good practice, and most code works well with them. But if
413 you prefer them unqualified, you can import the variants into scope:
417 enum Method { GET, POST }
421 If you want others to be able to import variants from your module directly, use
426 pub enum Method { GET, POST }
433 #### Note: this error code is no longer emitted by the compiler.
435 Patterns used to bind names must be irrefutable. That is, they must guarantee
436 that a name will be extracted in all cases. Instead of pattern matching the
437 loop variable, consider using a `match` or `if let` inside the loop body. For
440 ```compile_fail,E0005
441 let xs : Vec<Option<i32>> = vec![Some(1), None];
443 // This fails because `None` is not covered.
449 Match inside the loop instead:
452 let xs : Vec<Option<i32>> = vec![Some(1), None];
465 let xs : Vec<Option<i32>> = vec![Some(1), None];
468 if let Some(x) = item {
476 Mutable borrows are not allowed in pattern guards, because matching cannot have
477 side effects. Side effects could alter the matched object or the environment
478 on which the match depends in such a way, that the match would not be
479 exhaustive. For instance, the following would not match any arm if mutable
480 borrows were allowed:
482 ```compile_fail,E0301
485 option if option.take().is_none() => {
486 /* impossible, option is `Some` */
488 Some(_) => { } // When the previous match failed, the option became `None`.
494 Assignments are not allowed in pattern guards, because matching cannot have
495 side effects. Side effects could alter the matched object or the environment
496 on which the match depends in such a way, that the match would not be
497 exhaustive. For instance, the following would not match any arm if assignments
500 ```compile_fail,E0302
503 option if { option = None; false } => { },
504 Some(_) => { } // When the previous match failed, the option became `None`.
510 In certain cases it is possible for sub-bindings to violate memory safety.
511 Updates to the borrow checker in a future version of Rust may remove this
512 restriction, but for now patterns must be rewritten without sub-bindings.
516 ```compile_fail,E0303
517 match Some("hi".to_string()) {
518 ref op_string_ref @ Some(s) => {},
526 match Some("hi".to_string()) {
528 let op_string_ref = &Some(s);
535 The `op_string_ref` binding has type `&Option<&String>` in both cases.
537 See also https://github.com/rust-lang/rust/issues/14587
541 The value of statics and constants must be known at compile time, and they live
542 for the entire lifetime of a program. Creating a boxed value allocates memory on
543 the heap at runtime, and therefore cannot be done at compile time. Erroneous
546 ```compile_fail,E0010
547 #![feature(box_syntax)]
549 const CON : Box<i32> = box 0;
554 Static and const variables can refer to other const variables. But a const
555 variable cannot refer to a static variable. For example, `Y` cannot refer to
558 ```compile_fail,E0013
563 To fix this, the value can be extracted as a const and then used:
572 // FIXME(#24111) Change the language here when const fn stabilizes
574 The only functions that can be called in static or constant expressions are
575 `const` functions, and struct/enum constructors. `const` functions are only
576 available on a nightly compiler. Rust currently does not support more general
577 compile-time function execution.
580 const FOO: Option<u8> = Some(1); // enum constructor
582 const BAR: Bar = Bar {x: 1}; // struct constructor
585 See [RFC 911] for more details on the design of `const fn`s.
587 [RFC 911]: https://github.com/rust-lang/rfcs/blob/master/text/0911-const-fn.md
591 References in statics and constants may only refer to immutable values.
592 Erroneous code example:
594 ```compile_fail,E0017
598 // these three are not allowed:
599 const CR: &mut i32 = &mut C;
600 static STATIC_REF: &'static mut i32 = &mut X;
601 static CONST_REF: &'static mut i32 = &mut C;
604 Statics are shared everywhere, and if they refer to mutable data one might
605 violate memory safety since holding multiple mutable references to shared data
608 If you really want global mutable state, try using `static mut` or a global
613 A function call isn't allowed in the const's initialization expression
614 because the expression's value must be known at compile-time. Erroneous code
623 fn test(&self) -> i32 {
629 const FOO: Test = Test::V1;
631 const A: i32 = FOO.test(); // You can't call Test::func() here!
635 Remember: you can't use a function call inside a const's initialization
636 expression! However, you can totally use it anywhere else:
644 fn func(&self) -> i32 {
650 const FOO: Test = Test::V1;
652 FOO.func(); // here is good
653 let x = FOO.func(); // or even here!
659 Unsafe code was used outside of an unsafe function or block.
661 Erroneous code example:
663 ```compile_fail,E0133
664 unsafe fn f() { return; } // This is the unsafe code
667 f(); // error: call to unsafe function requires unsafe function or block
671 Using unsafe functionality is potentially dangerous and disallowed by safety
674 * Dereferencing raw pointers
675 * Calling functions via FFI
676 * Calling functions marked unsafe
678 These safety checks can be relaxed for a section of the code by wrapping the
679 unsafe instructions with an `unsafe` block. For instance:
682 unsafe fn f() { return; }
685 unsafe { f(); } // ok!
689 See also https://doc.rust-lang.org/book/first-edition/unsafe.html
693 This error occurs when an attempt is made to use data captured by a closure,
694 when that data may no longer exist. It's most commonly seen when attempting to
697 ```compile_fail,E0373
698 fn foo() -> Box<Fn(u32) -> u32> {
704 Notice that `x` is stack-allocated by `foo()`. By default, Rust captures
705 closed-over data by reference. This means that once `foo()` returns, `x` no
706 longer exists. An attempt to access `x` within the closure would thus be
709 Another situation where this might be encountered is when spawning threads:
711 ```compile_fail,E0373
716 let thr = std::thread::spawn(|| {
722 Since our new thread runs in parallel, the stack frame containing `x` and `y`
723 may well have disappeared by the time we try to use them. Even if we call
724 `thr.join()` within foo (which blocks until `thr` has completed, ensuring the
725 stack frame won't disappear), we will not succeed: the compiler cannot prove
726 that this behaviour is safe, and so won't let us do it.
728 The solution to this problem is usually to switch to using a `move` closure.
729 This approach moves (or copies, where possible) data into the closure, rather
730 than taking references to it. For example:
733 fn foo() -> Box<Fn(u32) -> u32> {
735 Box::new(move |y| x + y)
739 Now that the closure has its own copy of the data, there's no need to worry
744 It is not allowed to use or capture an uninitialized variable. For example:
746 ```compile_fail,E0381
749 let y = x; // error, use of possibly uninitialized variable
753 To fix this, ensure that any declared variables are initialized before being
765 This error occurs when an attempt is made to use a variable after its contents
766 have been moved elsewhere. For example:
768 ```compile_fail,E0382
769 struct MyStruct { s: u32 }
772 let mut x = MyStruct{ s: 5u32 };
779 Since `MyStruct` is a type that is not marked `Copy`, the data gets moved out
780 of `x` when we set `y`. This is fundamental to Rust's ownership system: outside
781 of workarounds like `Rc`, a value cannot be owned by more than one variable.
783 Sometimes we don't need to move the value. Using a reference, we can let another
784 function borrow the value without changing its ownership. In the example below,
785 we don't actually have to move our string to `calculate_length`, we can give it
786 a reference to it with `&` instead.
790 let s1 = String::from("hello");
792 let len = calculate_length(&s1);
794 println!("The length of '{}' is {}.", s1, len);
797 fn calculate_length(s: &String) -> usize {
802 A mutable reference can be created with `&mut`.
804 Sometimes we don't want a reference, but a duplicate. All types marked `Clone`
805 can be duplicated by calling `.clone()`. Subsequent changes to a clone do not
806 affect the original variable.
808 Most types in the standard library are marked `Clone`. The example below
809 demonstrates using `clone()` on a string. `s1` is first set to "many", and then
810 copied to `s2`. Then the first character of `s1` is removed, without affecting
811 `s2`. "any many" is printed to the console.
815 let mut s1 = String::from("many");
818 println!("{} {}", s1, s2);
822 If we control the definition of a type, we can implement `Clone` on it ourselves
823 with `#[derive(Clone)]`.
825 Some types have no ownership semantics at all and are trivial to duplicate. An
826 example is `i32` and the other number types. We don't have to call `.clone()` to
827 clone them, because they are marked `Copy` in addition to `Clone`. Implicit
828 cloning is more convenient in this case. We can mark our own types `Copy` if
829 all their members also are marked `Copy`.
831 In the example below, we implement a `Point` type. Because it only stores two
832 integers, we opt-out of ownership semantics with `Copy`. Then we can
833 `let p2 = p1` without `p1` being moved.
836 #[derive(Copy, Clone)]
837 struct Point { x: i32, y: i32 }
840 let mut p1 = Point{ x: -1, y: 2 };
843 println!("p1: {}, {}", p1.x, p1.y);
844 println!("p2: {}, {}", p2.x, p2.y);
848 Alternatively, if we don't control the struct's definition, or mutable shared
849 ownership is truly required, we can use `Rc` and `RefCell`:
852 use std::cell::RefCell;
855 struct MyStruct { s: u32 }
858 let mut x = Rc::new(RefCell::new(MyStruct{ s: 5u32 }));
860 x.borrow_mut().s = 6;
861 println!("{}", x.borrow().s);
865 With this approach, x and y share ownership of the data via the `Rc` (reference
866 count type). `RefCell` essentially performs runtime borrow checking: ensuring
867 that at most one writer or multiple readers can access the data at any one time.
869 If you wish to learn more about ownership in Rust, start with the chapter in the
872 https://doc.rust-lang.org/book/first-edition/ownership.html
876 This error occurs when an attempt is made to partially reinitialize a
877 structure that is currently uninitialized.
879 For example, this can happen when a drop has taken place:
881 ```compile_fail,E0383
886 fn drop(&mut self) { /* ... */ }
889 let mut x = Foo { a: 1 };
890 drop(x); // `x` is now uninitialized
891 x.a = 2; // error, partial reinitialization of uninitialized structure `t`
894 This error can be fixed by fully reinitializing the structure in question:
901 fn drop(&mut self) { /* ... */ }
904 let mut x = Foo { a: 1 };
911 This error occurs when an attempt is made to reassign an immutable variable.
914 ```compile_fail,E0384
917 x = 5; // error, reassignment of immutable variable
921 By default, variables in Rust are immutable. To fix this error, add the keyword
922 `mut` after the keyword `let` when declaring the variable. For example:
933 This error occurs when an attempt is made to mutate the target of a mutable
934 reference stored inside an immutable container.
936 For example, this can happen when storing a `&mut` inside an immutable `Box`:
938 ```compile_fail,E0386
940 let y: Box<_> = Box::new(&mut x);
941 **y = 2; // error, cannot assign to data in an immutable container
944 This error can be fixed by making the container mutable:
948 let mut y: Box<_> = Box::new(&mut x);
952 It can also be fixed by using a type with interior mutability, such as `Cell`
959 let y: Box<Cell<_>> = Box::new(Cell::new(x));
965 This error occurs when an attempt is made to mutate or mutably reference data
966 that a closure has captured immutably. Examples of this error are shown below:
968 ```compile_fail,E0387
969 // Accepts a function or a closure that captures its environment immutably.
970 // Closures passed to foo will not be able to mutate their closed-over state.
971 fn foo<F: Fn()>(f: F) { }
973 // Attempts to mutate closed-over data. Error message reads:
974 // `cannot assign to data in a captured outer variable...`
980 // Attempts to take a mutable reference to closed-over data. Error message
981 // reads: `cannot borrow data mutably in a captured outer variable...`
984 foo(|| { let y = &mut x; });
988 The problem here is that foo is defined as accepting a parameter of type `Fn`.
989 Closures passed into foo will thus be inferred to be of type `Fn`, meaning that
990 they capture their context immutably.
992 If the definition of `foo` is under your control, the simplest solution is to
993 capture the data mutably. This can be done by defining `foo` to take FnMut
997 fn foo<F: FnMut()>(f: F) { }
1000 Alternatively, we can consider using the `Cell` and `RefCell` types to achieve
1001 interior mutability through a shared reference. Our example's `mutable`
1002 function could be redefined as below:
1005 use std::cell::Cell;
1007 fn foo<F: Fn()>(f: F) { }
1010 let x = Cell::new(0u32);
1015 You can read more about cell types in the API documentation:
1017 https://doc.rust-lang.org/std/cell/
1021 E0388 was removed and is no longer issued.
1025 An attempt was made to mutate data using a non-mutable reference. This
1026 commonly occurs when attempting to assign to a non-mutable reference of a
1027 mutable reference (`&(&mut T)`).
1029 Example of erroneous code:
1031 ```compile_fail,E0389
1037 let mut fancy = FancyNum{ num: 5 };
1038 let fancy_ref = &(&mut fancy);
1039 fancy_ref.num = 6; // error: cannot assign to data in a `&` reference
1040 println!("{}", fancy_ref.num);
1044 Here, `&mut fancy` is mutable, but `&(&mut fancy)` is not. Creating an
1045 immutable reference to a value borrows it immutably. There can be multiple
1046 references of type `&(&mut T)` that point to the same value, so they must be
1047 immutable to prevent multiple mutable references to the same value.
1049 To fix this, either remove the outer reference:
1057 let mut fancy = FancyNum{ num: 5 };
1059 let fancy_ref = &mut fancy;
1060 // `fancy_ref` is now &mut FancyNum, rather than &(&mut FancyNum)
1062 fancy_ref.num = 6; // No error!
1064 println!("{}", fancy_ref.num);
1068 Or make the outer reference mutable:
1076 let mut fancy = FancyNum{ num: 5 };
1078 let fancy_ref = &mut (&mut fancy);
1079 // `fancy_ref` is now &mut(&mut FancyNum), rather than &(&mut FancyNum)
1081 fancy_ref.num = 6; // No error!
1083 println!("{}", fancy_ref.num);
1089 A value was moved. However, its size was not known at compile time, and only
1090 values of a known size can be moved.
1092 Erroneous code example:
1095 #![feature(box_syntax)]
1098 let array: &[isize] = &[1, 2, 3];
1099 let _x: Box<[isize]> = box *array;
1100 // error: cannot move a value of type [isize]: the size of [isize] cannot
1101 // be statically determined
1105 In Rust, you can only move a value when its size is known at compile time.
1107 To work around this restriction, consider "hiding" the value behind a reference:
1108 either `&x` or `&mut x`. Since a reference has a fixed size, this lets you move
1109 it around as usual. Example:
1112 #![feature(box_syntax)]
1115 let array: &[isize] = &[1, 2, 3];
1116 let _x: Box<&[isize]> = box array; // ok!
1122 A borrow of a constant containing interior mutability was attempted. Erroneous
1125 ```compile_fail,E0492
1126 use std::sync::atomic::{AtomicUsize, ATOMIC_USIZE_INIT};
1128 const A: AtomicUsize = ATOMIC_USIZE_INIT;
1129 static B: &'static AtomicUsize = &A;
1130 // error: cannot borrow a constant which may contain interior mutability,
1131 // create a static instead
1134 A `const` represents a constant value that should never change. If one takes
1135 a `&` reference to the constant, then one is taking a pointer to some memory
1136 location containing the value. Normally this is perfectly fine: most values
1137 can't be changed via a shared `&` pointer, but interior mutability would allow
1138 it. That is, a constant value could be mutated. On the other hand, a `static` is
1139 explicitly a single memory location, which can be mutated at will.
1141 So, in order to solve this error, either use statics which are `Sync`:
1144 use std::sync::atomic::{AtomicUsize, ATOMIC_USIZE_INIT};
1146 static A: AtomicUsize = ATOMIC_USIZE_INIT;
1147 static B: &'static AtomicUsize = &A; // ok!
1150 You can also have this error while using a cell type:
1152 ```compile_fail,E0492
1153 use std::cell::Cell;
1155 const A: Cell<usize> = Cell::new(1);
1156 const B: &Cell<usize> = &A;
1157 // error: cannot borrow a constant which may contain interior mutability,
1158 // create a static instead
1161 struct C { a: Cell<usize> }
1163 const D: C = C { a: Cell::new(1) };
1164 const E: &Cell<usize> = &D.a; // error
1167 const F: &C = &D; // error
1170 This is because cell types do operations that are not thread-safe. Due to this,
1171 they don't implement Sync and thus can't be placed in statics.
1173 However, if you still wish to use these types, you can achieve this by an unsafe
1177 use std::cell::Cell;
1178 use std::marker::Sync;
1180 struct NotThreadSafe<T> {
1184 unsafe impl<T> Sync for NotThreadSafe<T> {}
1186 static A: NotThreadSafe<usize> = NotThreadSafe { value : Cell::new(1) };
1187 static B: &'static NotThreadSafe<usize> = &A; // ok!
1190 Remember this solution is unsafe! You will have to ensure that accesses to the
1191 cell are synchronized.
1195 A variable was borrowed as mutable more than once. Erroneous code example:
1197 ```compile_fail,E0499
1201 // error: cannot borrow `i` as mutable more than once at a time
1204 Please note that in rust, you can either have many immutable references, or one
1205 mutable reference. Take a look at
1206 https://doc.rust-lang.org/stable/book/references-and-borrowing.html for more
1207 information. Example:
1212 let mut x = &mut i; // ok!
1217 let b = &i; // still ok!
1218 let c = &i; // still ok!
1223 A borrowed variable was used in another closure. Example of erroneous code:
1226 fn you_know_nothing(jon_snow: &mut i32) {
1227 let nights_watch = || {
1231 *jon_snow = 3; // error: closure requires unique access to `jon_snow`
1232 // but it is already borrowed
1237 In here, `jon_snow` is already borrowed by the `nights_watch` closure, so it
1238 cannot be borrowed by the `starks` closure at the same time. To fix this issue,
1239 you can put the closure in its own scope:
1242 fn you_know_nothing(jon_snow: &mut i32) {
1244 let nights_watch = || {
1247 } // At this point, `jon_snow` is free.
1254 Or, if the type implements the `Clone` trait, you can clone it between
1258 fn you_know_nothing(jon_snow: &mut i32) {
1259 let mut jon_copy = jon_snow.clone();
1260 let nights_watch = || {
1271 This error indicates that a mutable variable is being used while it is still
1272 captured by a closure. Because the closure has borrowed the variable, it is not
1273 available for use until the closure goes out of scope.
1275 Note that a capture will either move or borrow a variable, but in this
1276 situation, the closure is borrowing the variable. Take a look at
1277 http://rustbyexample.com/fn/closures/capture.html for more information about
1280 Example of erroneous code:
1282 ```compile_fail,E0501
1283 fn inside_closure(x: &mut i32) {
1284 // Actions which require unique access
1287 fn outside_closure(x: &mut i32) {
1288 // Actions which require unique access
1291 fn foo(a: &mut i32) {
1295 outside_closure(a); // error: cannot borrow `*a` as mutable because previous
1296 // closure requires unique access.
1300 To fix this error, you can place the closure in its own scope:
1303 fn inside_closure(x: &mut i32) {}
1304 fn outside_closure(x: &mut i32) {}
1306 fn foo(a: &mut i32) {
1311 } // borrow on `a` ends.
1312 outside_closure(a); // ok!
1316 Or you can pass the variable as a parameter to the closure:
1319 fn inside_closure(x: &mut i32) {}
1320 fn outside_closure(x: &mut i32) {}
1322 fn foo(a: &mut i32) {
1323 let bar = |s: &mut i32| {
1331 It may be possible to define the closure later:
1334 fn inside_closure(x: &mut i32) {}
1335 fn outside_closure(x: &mut i32) {}
1337 fn foo(a: &mut i32) {
1347 This error indicates that you are trying to borrow a variable as mutable when it
1348 has already been borrowed as immutable.
1350 Example of erroneous code:
1352 ```compile_fail,E0502
1353 fn bar(x: &mut i32) {}
1354 fn foo(a: &mut i32) {
1355 let ref y = a; // a is borrowed as immutable.
1356 bar(a); // error: cannot borrow `*a` as mutable because `a` is also borrowed
1361 To fix this error, ensure that you don't have any other references to the
1362 variable before trying to access it mutably:
1365 fn bar(x: &mut i32) {}
1366 fn foo(a: &mut i32) {
1368 let ref y = a; // ok!
1372 For more information on the rust ownership system, take a look at
1373 https://doc.rust-lang.org/stable/book/references-and-borrowing.html.
1377 A value was used after it was mutably borrowed.
1379 Example of erroneous code:
1381 ```compile_fail,E0503
1384 // Create a mutable borrow of `value`. This borrow
1385 // lives until the end of this function.
1386 let _borrow = &mut value;
1387 let _sum = value + 1; // error: cannot use `value` because
1388 // it was mutably borrowed
1392 In this example, `value` is mutably borrowed by `borrow` and cannot be
1393 used to calculate `sum`. This is not possible because this would violate
1394 Rust's mutability rules.
1396 You can fix this error by limiting the scope of the borrow:
1401 // By creating a new block, you can limit the scope
1402 // of the reference.
1404 let _borrow = &mut value; // Use `_borrow` inside this block.
1406 // The block has ended and with it the borrow.
1407 // You can now use `value` again.
1408 let _sum = value + 1;
1412 Or by cloning `value` before borrowing it:
1417 // We clone `value`, creating a copy.
1418 let value_cloned = value.clone();
1419 // The mutable borrow is a reference to `value` and
1420 // not to `value_cloned`...
1421 let _borrow = &mut value;
1422 // ... which means we can still use `value_cloned`,
1423 let _sum = value_cloned + 1;
1424 // even though the borrow only ends here.
1428 You can find more information about borrowing in the rust-book:
1429 http://doc.rust-lang.org/stable/book/references-and-borrowing.html
1433 This error occurs when an attempt is made to move a borrowed variable into a
1436 Example of erroneous code:
1438 ```compile_fail,E0504
1444 let fancy_num = FancyNum { num: 5 };
1445 let fancy_ref = &fancy_num;
1448 println!("child function: {}", fancy_num.num);
1449 // error: cannot move `fancy_num` into closure because it is borrowed
1453 println!("main function: {}", fancy_ref.num);
1457 Here, `fancy_num` is borrowed by `fancy_ref` and so cannot be moved into
1458 the closure `x`. There is no way to move a value into a closure while it is
1459 borrowed, as that would invalidate the borrow.
1461 If the closure can't outlive the value being moved, try using a reference
1470 let fancy_num = FancyNum { num: 5 };
1471 let fancy_ref = &fancy_num;
1474 // fancy_ref is usable here because it doesn't move `fancy_num`
1475 println!("child function: {}", fancy_ref.num);
1480 println!("main function: {}", fancy_num.num);
1484 If the value has to be borrowed and then moved, try limiting the lifetime of
1485 the borrow using a scoped block:
1493 let fancy_num = FancyNum { num: 5 };
1496 let fancy_ref = &fancy_num;
1497 println!("main function: {}", fancy_ref.num);
1498 // `fancy_ref` goes out of scope here
1502 // `fancy_num` can be moved now (no more references exist)
1503 println!("child function: {}", fancy_num.num);
1510 If the lifetime of a reference isn't enough, such as in the case of threading,
1511 consider using an `Arc` to create a reference-counted value:
1522 let fancy_ref1 = Arc::new(FancyNum { num: 5 });
1523 let fancy_ref2 = fancy_ref1.clone();
1525 let x = thread::spawn(move || {
1526 // `fancy_ref1` can be moved and has a `'static` lifetime
1527 println!("child thread: {}", fancy_ref1.num);
1530 x.join().expect("child thread should finish");
1531 println!("main thread: {}", fancy_ref2.num);
1537 A value was moved out while it was still borrowed.
1539 Erroneous code example:
1541 ```compile_fail,E0505
1544 fn eat(val: Value) {}
1549 let _ref_to_val: &Value = &x;
1555 Here, the function `eat` takes the ownership of `x`. However,
1556 `x` cannot be moved because it was borrowed to `_ref_to_val`.
1557 To fix that you can do few different things:
1559 * Try to avoid moving the variable.
1560 * Release borrow before move.
1561 * Implement the `Copy` trait on the type.
1568 fn eat(val: &Value) {}
1573 let _ref_to_val: &Value = &x;
1574 eat(&x); // pass by reference, if it's possible
1584 fn eat(val: Value) {}
1589 let _ref_to_val: &Value = &x;
1591 eat(x); // release borrow and then move it.
1598 #[derive(Clone, Copy)] // implement Copy trait
1601 fn eat(val: Value) {}
1606 let _ref_to_val: &Value = &x;
1607 eat(x); // it will be copied here.
1612 You can find more information about borrowing in the rust-book:
1613 http://doc.rust-lang.org/stable/book/references-and-borrowing.html
1617 This error occurs when an attempt is made to assign to a borrowed value.
1619 Example of erroneous code:
1621 ```compile_fail,E0506
1627 let mut fancy_num = FancyNum { num: 5 };
1628 let fancy_ref = &fancy_num;
1629 fancy_num = FancyNum { num: 6 };
1630 // error: cannot assign to `fancy_num` because it is borrowed
1632 println!("Num: {}, Ref: {}", fancy_num.num, fancy_ref.num);
1636 Because `fancy_ref` still holds a reference to `fancy_num`, `fancy_num` can't
1637 be assigned to a new value as it would invalidate the reference.
1639 Alternatively, we can move out of `fancy_num` into a second `fancy_num`:
1647 let mut fancy_num = FancyNum { num: 5 };
1648 let moved_num = fancy_num;
1649 fancy_num = FancyNum { num: 6 };
1651 println!("Num: {}, Moved num: {}", fancy_num.num, moved_num.num);
1655 If the value has to be borrowed, try limiting the lifetime of the borrow using
1664 let mut fancy_num = FancyNum { num: 5 };
1667 let fancy_ref = &fancy_num;
1668 println!("Ref: {}", fancy_ref.num);
1671 // Works because `fancy_ref` is no longer in scope
1672 fancy_num = FancyNum { num: 6 };
1673 println!("Num: {}", fancy_num.num);
1677 Or by moving the reference into a function:
1685 let mut fancy_num = FancyNum { num: 5 };
1687 print_fancy_ref(&fancy_num);
1689 // Works because function borrow has ended
1690 fancy_num = FancyNum { num: 6 };
1691 println!("Num: {}", fancy_num.num);
1694 fn print_fancy_ref(fancy_ref: &FancyNum){
1695 println!("Ref: {}", fancy_ref.num);
1701 You tried to move out of a value which was borrowed. Erroneous code example:
1703 ```compile_fail,E0507
1704 use std::cell::RefCell;
1706 struct TheDarkKnight;
1708 impl TheDarkKnight {
1709 fn nothing_is_true(self) {}
1713 let x = RefCell::new(TheDarkKnight);
1715 x.borrow().nothing_is_true(); // error: cannot move out of borrowed content
1719 Here, the `nothing_is_true` method takes the ownership of `self`. However,
1720 `self` cannot be moved because `.borrow()` only provides an `&TheDarkKnight`,
1721 which is a borrow of the content owned by the `RefCell`. To fix this error,
1722 you have three choices:
1724 * Try to avoid moving the variable.
1725 * Somehow reclaim the ownership.
1726 * Implement the `Copy` trait on the type.
1731 use std::cell::RefCell;
1733 struct TheDarkKnight;
1735 impl TheDarkKnight {
1736 fn nothing_is_true(&self) {} // First case, we don't take ownership
1740 let x = RefCell::new(TheDarkKnight);
1742 x.borrow().nothing_is_true(); // ok!
1749 use std::cell::RefCell;
1751 struct TheDarkKnight;
1753 impl TheDarkKnight {
1754 fn nothing_is_true(self) {}
1758 let x = RefCell::new(TheDarkKnight);
1759 let x = x.into_inner(); // we get back ownership
1761 x.nothing_is_true(); // ok!
1768 use std::cell::RefCell;
1770 #[derive(Clone, Copy)] // we implement the Copy trait
1771 struct TheDarkKnight;
1773 impl TheDarkKnight {
1774 fn nothing_is_true(self) {}
1778 let x = RefCell::new(TheDarkKnight);
1780 x.borrow().nothing_is_true(); // ok!
1784 Moving a member out of a mutably borrowed struct will also cause E0507 error:
1786 ```compile_fail,E0507
1787 struct TheDarkKnight;
1789 impl TheDarkKnight {
1790 fn nothing_is_true(self) {}
1794 knight: TheDarkKnight
1798 let mut cave = Batcave {
1799 knight: TheDarkKnight
1801 let borrowed = &mut cave;
1803 borrowed.knight.nothing_is_true(); // E0507
1807 It is fine only if you put something back. `mem::replace` can be used for that:
1810 # struct TheDarkKnight;
1811 # impl TheDarkKnight { fn nothing_is_true(self) {} }
1812 # struct Batcave { knight: TheDarkKnight }
1815 let mut cave = Batcave {
1816 knight: TheDarkKnight
1818 let borrowed = &mut cave;
1820 mem::replace(&mut borrowed.knight, TheDarkKnight).nothing_is_true(); // ok!
1823 You can find more information about borrowing in the rust-book:
1824 http://doc.rust-lang.org/book/first-edition/references-and-borrowing.html
1828 A value was moved out of a non-copy fixed-size array.
1830 Example of erroneous code:
1832 ```compile_fail,E0508
1836 let array = [NonCopy; 1];
1837 let _value = array[0]; // error: cannot move out of type `[NonCopy; 1]`,
1838 // a non-copy fixed-size array
1842 The first element was moved out of the array, but this is not
1843 possible because `NonCopy` does not implement the `Copy` trait.
1845 Consider borrowing the element instead of moving it:
1851 let array = [NonCopy; 1];
1852 let _value = &array[0]; // Borrowing is allowed, unlike moving.
1856 Alternatively, if your type implements `Clone` and you need to own the value,
1857 consider borrowing and then cloning:
1864 let array = [NonCopy; 1];
1865 // Now you can clone the array element.
1866 let _value = array[0].clone();
1872 This error occurs when an attempt is made to move out of a value whose type
1873 implements the `Drop` trait.
1875 Example of erroneous code:
1877 ```compile_fail,E0509
1886 impl Drop for DropStruct {
1887 fn drop(&mut self) {
1888 // Destruct DropStruct, possibly using FancyNum
1893 let drop_struct = DropStruct{fancy: FancyNum{num: 5}};
1894 let fancy_field = drop_struct.fancy; // Error E0509
1895 println!("Fancy: {}", fancy_field.num);
1896 // implicit call to `drop_struct.drop()` as drop_struct goes out of scope
1900 Here, we tried to move a field out of a struct of type `DropStruct` which
1901 implements the `Drop` trait. However, a struct cannot be dropped if one or
1902 more of its fields have been moved.
1904 Structs implementing the `Drop` trait have an implicit destructor that gets
1905 called when they go out of scope. This destructor may use the fields of the
1906 struct, so moving out of the struct could make it impossible to run the
1907 destructor. Therefore, we must think of all values whose type implements the
1908 `Drop` trait as single units whose fields cannot be moved.
1910 This error can be fixed by creating a reference to the fields of a struct,
1911 enum, or tuple using the `ref` keyword:
1922 impl Drop for DropStruct {
1923 fn drop(&mut self) {
1924 // Destruct DropStruct, possibly using FancyNum
1929 let drop_struct = DropStruct{fancy: FancyNum{num: 5}};
1930 let ref fancy_field = drop_struct.fancy; // No more errors!
1931 println!("Fancy: {}", fancy_field.num);
1932 // implicit call to `drop_struct.drop()` as drop_struct goes out of scope
1936 Note that this technique can also be used in the arms of a match expression:
1947 impl Drop for DropEnum {
1948 fn drop(&mut self) {
1949 // Destruct DropEnum, possibly using FancyNum
1954 // Creates and enum of type `DropEnum`, which implements `Drop`
1955 let drop_enum = DropEnum::Fancy(FancyNum{num: 10});
1957 // Creates a reference to the inside of `DropEnum::Fancy`
1958 DropEnum::Fancy(ref fancy_field) => // No error!
1959 println!("It was fancy-- {}!", fancy_field.num),
1961 // implicit call to `drop_enum.drop()` as drop_enum goes out of scope
1967 Cannot mutate place in this match guard.
1969 When matching on a variable it cannot be mutated in the match guards, as this
1970 could cause the match to be non-exhaustive:
1972 ```compile_fail,E0510
1973 #![feature(nll, bind_by_move_pattern_guards)]
1974 let mut x = Some(0);
1977 Some(v) if { x = None; false } => (),
1978 Some(_) => (), // No longer matches
1982 Here executing `x = None` would modify the value being matched and require us
1983 to go "back in time" to the `None` arm.
1987 When matching against an exclusive range, the compiler verifies that the range
1988 is non-empty. Exclusive range patterns include the start point but not the end
1989 point, so this is equivalent to requiring the start of the range to be less
1990 than the end of the range.
1996 // This range is ok, albeit pointless.
1998 // This range is empty, and the compiler can tell.
2005 Cannot return value that references local variable
2007 Local variables, function parameters and temporaries are all dropped before the
2008 end of the function body. So a reference to them cannot be returned.
2010 ```compile_fail,E0515
2012 fn get_dangling_reference() -> &'static i32 {
2018 ```compile_fail,E0515
2020 use std::slice::Iter;
2021 fn get_dangling_iterator<'a>() -> Iter<'a, i32> {
2022 let v = vec![1, 2, 3];
2027 Consider returning an owned value instead:
2030 use std::vec::IntoIter;
2032 fn get_integer() -> i32 {
2037 fn get_owned_iterator() -> IntoIter<i32> {
2038 let v = vec![1, 2, 3];
2045 Closures cannot mutate immutable captured variables.
2047 Erroneous code example:
2049 ```compile_fail,E0595
2050 let x = 3; // error: closure cannot assign to immutable local variable `x`
2051 let mut c = || { x += 1 };
2054 Make the variable binding mutable:
2057 let mut x = 3; // ok!
2058 let mut c = || { x += 1 };
2063 This error occurs because you tried to mutably borrow a non-mutable variable.
2065 Example of erroneous code:
2067 ```compile_fail,E0596
2069 let y = &mut x; // error: cannot borrow mutably
2072 In here, `x` isn't mutable, so when we try to mutably borrow it in `y`, it
2073 fails. To fix this error, you need to make `x` mutable:
2077 let y = &mut x; // ok!
2082 This error occurs because a borrow was made inside a variable which has a
2083 greater lifetime than the borrowed one.
2085 Example of erroneous code:
2087 ```compile_fail,E0597
2092 let mut x = Foo { x: None };
2094 x.x = Some(&y); // error: `y` does not live long enough
2097 In here, `x` is created before `y` and therefore has a greater lifetime. Always
2098 keep in mind that values in a scope are dropped in the opposite order they are
2099 created. So to fix the previous example, just make the `y` lifetime greater than
2108 let mut x = Foo { x: None };
2114 This error occurs because a borrow in a generator persists across a
2117 ```compile_fail,E0626
2118 # #![feature(generators, generator_trait)]
2119 # use std::ops::Generator;
2121 let a = &String::new(); // <-- This borrow...
2122 yield (); // ...is still in scope here, when the yield occurs.
2125 unsafe { b.resume() };
2128 At present, it is not permitted to have a yield that occurs while a
2129 borrow is still in scope. To resolve this error, the borrow must
2130 either be "contained" to a smaller scope that does not overlap the
2131 yield or else eliminated in another way. So, for example, we might
2132 resolve the previous example by removing the borrow and just storing
2133 the integer by value:
2136 # #![feature(generators, generator_trait)]
2137 # use std::ops::Generator;
2143 unsafe { b.resume() };
2146 This is a very simple case, of course. In more complex cases, we may
2147 wish to have more than one reference to the value that was borrowed --
2148 in those cases, something like the `Rc` or `Arc` types may be useful.
2150 This error also frequently arises with iteration:
2152 ```compile_fail,E0626
2153 # #![feature(generators, generator_trait)]
2154 # use std::ops::Generator;
2156 let v = vec![1,2,3];
2157 for &x in &v { // <-- borrow of `v` is still in scope...
2158 yield x; // ...when this yield occurs.
2161 unsafe { b.resume() };
2164 Such cases can sometimes be resolved by iterating "by value" (or using
2165 `into_iter()`) to avoid borrowing:
2168 # #![feature(generators, generator_trait)]
2169 # use std::ops::Generator;
2171 let v = vec![1,2,3];
2172 for x in v { // <-- Take ownership of the values instead!
2173 yield x; // <-- Now yield is OK.
2176 unsafe { b.resume() };
2179 If taking ownership is not an option, using indices can work too:
2182 # #![feature(generators, generator_trait)]
2183 # use std::ops::Generator;
2185 let v = vec![1,2,3];
2186 let len = v.len(); // (*)
2188 let x = v[i]; // (*)
2189 yield x; // <-- Now yield is OK.
2192 unsafe { b.resume() };
2194 // (*) -- Unfortunately, these temporaries are currently required.
2195 // See <https://github.com/rust-lang/rust/issues/43122>.
2200 This error occurs because a borrow of a thread-local variable was made inside a
2201 function which outlived the lifetime of the function.
2203 Example of erroneous code:
2205 ```compile_fail,E0712
2207 #![feature(thread_local)]
2213 let a = &FOO; // error: thread-local variable borrowed past end of function
2215 std::thread::spawn(move || {
2223 This error occurs when an attempt is made to borrow state past the end of the
2224 lifetime of a type that implements the `Drop` trait.
2226 Example of erroneous code:
2228 ```compile_fail,E0713
2231 pub struct S<'a> { data: &'a mut String }
2233 impl<'a> Drop for S<'a> {
2234 fn drop(&mut self) { self.data.push_str("being dropped"); }
2237 fn demo<'a>(s: S<'a>) -> &'a mut String { let p = &mut *s.data; p }
2240 Here, `demo` tries to borrow the string data held within its
2241 argument `s` and then return that borrow. However, `S` is
2242 declared as implementing `Drop`.
2244 Structs implementing the `Drop` trait have an implicit destructor that
2245 gets called when they go out of scope. This destructor gets exclusive
2246 access to the fields of the struct when it runs.
2248 This means that when `s` reaches the end of `demo`, its destructor
2249 gets exclusive access to its `&mut`-borrowed string data. allowing
2250 another borrow of that string data (`p`), to exist across the drop of
2251 `s` would be a violation of the principle that `&mut`-borrows have
2252 exclusive, unaliased access to their referenced data.
2254 This error can be fixed by changing `demo` so that the destructor does
2255 not run while the string-data is borrowed; for example by taking `S`
2261 pub struct S<'a> { data: &'a mut String }
2263 impl<'a> Drop for S<'a> {
2264 fn drop(&mut self) { self.data.push_str("being dropped"); }
2267 fn demo<'a>(s: &'a mut S<'a>) -> &'a mut String { let p = &mut *(*s).data; p }
2270 Note that this approach needs a reference to S with lifetime `'a`.
2271 Nothing shorter than `'a` will suffice: a shorter lifetime would imply
2272 that after `demo` finishes executing, something else (such as the
2273 destructor!) could access `s.data` after the end of that shorter
2274 lifetime, which would again violate the `&mut`-borrow's exclusive
2279 This error indicates that a temporary value is being dropped
2280 while a borrow is still in active use.
2282 Erroneous code example:
2284 ```compile_fail,E0716
2286 fn foo() -> i32 { 22 }
2287 fn bar(x: &i32) -> &i32 { x }
2288 let p = bar(&foo());
2289 // ------ creates a temporary
2293 Here, the expression `&foo()` is borrowing the expression
2294 `foo()`. As `foo()` is call to a function, and not the name of
2295 a variable, this creates a **temporary** -- that temporary stores
2296 the return value from `foo()` so that it can be borrowed.
2297 So you might imagine that `let p = bar(&foo())` is equivalent
2300 ```compile_fail,E0597
2301 # fn foo() -> i32 { 22 }
2302 # fn bar(x: &i32) -> &i32 { x }
2304 let tmp = foo(); // the temporary
2306 }; // <-- tmp is freed as we exit this block
2310 Whenever a temporary is created, it is automatically dropped (freed)
2311 according to fixed rules. Ordinarily, the temporary is dropped
2312 at the end of the enclosing statement -- in this case, after the `let`.
2313 This is illustrated in the example above by showing that `tmp` would
2314 be freed as we exit the block.
2316 To fix this problem, you need to create a local variable
2317 to store the value in rather than relying on a temporary.
2318 For example, you might change the original program to
2322 fn foo() -> i32 { 22 }
2323 fn bar(x: &i32) -> &i32 { x }
2324 let value = foo(); // dropped at the end of the enclosing block
2325 let p = bar(&value);
2329 By introducing the explicit `let value`, we allocate storage
2330 that will last until the end of the enclosing block (when `value`
2331 goes out of scope). When we borrow `&value`, we are borrowing a
2332 local variable that already exists, and hence no temporary is created.
2334 Temporaries are not always dropped at the end of the enclosing
2335 statement. In simple cases where the `&` expression is immediately
2336 stored into a variable, the compiler will automatically extend
2337 the lifetime of the temporary until the end of the enclosinb
2338 block. Therefore, an alternative way to fix the original
2339 program is to write `let tmp = &foo()` and not `let tmp = foo()`:
2342 fn foo() -> i32 { 22 }
2343 fn bar(x: &i32) -> &i32 { x }
2349 Here, we are still borrowing `foo()`, but as the borrow is assigned
2350 directly into a variable, the temporary will not be dropped until
2351 the end of the enclosing block. Similar rules apply when temporaries
2352 are stored into aggregate structures like a tuple or struct:
2355 // Here, two temporaries are created, but
2356 // as they are stored directly into `value`,
2357 // they are not dropped until the end of the
2359 fn foo() -> i32 { 22 }
2360 let value = (&foo(), &foo());
2366 register_diagnostics! {
2367 // E0298, // cannot compare constants
2368 // E0299, // mismatched types between arms
2369 // E0471, // constant evaluation error (in pattern)
2370 // E0385, // {} in an aliasable location
2371 E0493, // destructors cannot be evaluated at compile-time
2372 E0521, // borrowed data escapes outside of closure
2373 E0524, // two closures require unique access to `..` at the same time
2374 E0526, // shuffle indices are not constant
2375 E0594, // cannot assign to {}
2376 E0598, // lifetime of {} is too short to guarantee its contents can be...
2377 E0625, // thread-local statics cannot be accessed at compile-time