1 syntax::register_diagnostics! {
5 #### Note: this error code is no longer emitted by the compiler.
7 This error suggests that the expression arm corresponding to the noted pattern
8 will never be reached as for all possible values of the expression being
9 matched, one of the preceding patterns will match.
11 This means that perhaps some of the preceding patterns are too general, this
12 one is too specific or the ordering is incorrect.
14 For example, the following `match` block has too many arms:
18 Some(bar) => {/* ... */}
19 x => {/* ... */} // This handles the `None` case
20 _ => {/* ... */} // All possible cases have already been handled
24 `match` blocks have their patterns matched in order, so, for example, putting
25 a wildcard arm above a more specific arm will make the latter arm irrelevant.
27 Ensure the ordering of the match arm is correct and remove any superfluous
32 #### Note: this error code is no longer emitted by the compiler.
34 This error indicates that an empty match expression is invalid because the type
35 it is matching on is non-empty (there exist values of this type). In safe code
36 it is impossible to create an instance of an empty type, so empty match
37 expressions are almost never desired. This error is typically fixed by adding
38 one or more cases to the match expression.
40 An example of an empty type is `enum Empty { }`. So, the following will work:
55 fn foo(x: Option<String>) {
64 This error indicates that the compiler cannot guarantee a matching pattern for
65 one or more possible inputs to a match expression. Guaranteed matches are
66 required in order to assign values to match expressions, or alternatively,
67 determine the flow of execution. Erroneous code example:
75 let x = Terminator::HastaLaVistaBaby;
77 match x { // error: non-exhaustive patterns: `HastaLaVistaBaby` not covered
78 Terminator::TalkToMyHand => {}
82 If you encounter this error you must alter your patterns so that every possible
83 value of the input type is matched. For types with a small number of variants
84 (like enums) you should probably cover all cases explicitly. Alternatively, the
85 underscore `_` wildcard pattern can be added after all other patterns to match
86 "anything else". Example:
94 let x = Terminator::HastaLaVistaBaby;
97 Terminator::TalkToMyHand => {}
98 Terminator::HastaLaVistaBaby => {}
104 Terminator::TalkToMyHand => {}
111 Patterns used to bind names must be irrefutable, that is, they must guarantee
112 that a name will be extracted in all cases. Erroneous code example:
114 ```compile_fail,E0005
117 // error: refutable pattern in local binding: `None` not covered
120 If you encounter this error you probably need to use a `match` or `if let` to
121 deal with the possibility of failure. Example:
142 This error indicates that the bindings in a match arm would require a value to
143 be moved into more than one location, thus violating unique ownership. Code
144 like the following is invalid as it requires the entire `Option<String>` to be
145 moved into a variable called `op_string` while simultaneously requiring the
146 inner `String` to be moved into a variable called `s`.
148 ```compile_fail,E0007
149 let x = Some("s".to_string());
152 op_string @ Some(s) => {}, // error: cannot bind by-move with sub-bindings
157 See also the error E0303.
161 In a pattern, all values that don't implement the `Copy` trait have to be bound
162 the same way. The goal here is to avoid binding simultaneously by-move and
165 This limitation may be removed in a future version of Rust.
167 Erroneous code example:
169 ```compile_fail,E0009
172 let x = Some((X { x: () }, X { x: () }));
174 Some((y, ref z)) => {}, // error: cannot bind by-move and by-ref in the
180 You have two solutions:
182 Solution #1: Bind the pattern's values the same way.
187 let x = Some((X { x: () }, X { x: () }));
189 Some((ref y, ref z)) => {},
190 // or Some((y, z)) => {}
195 Solution #2: Implement the `Copy` trait for the `X` structure.
197 However, please keep in mind that the first solution should be preferred.
200 #[derive(Clone, Copy)]
203 let x = Some((X { x: () }, X { x: () }));
205 Some((y, ref z)) => {},
212 The value of statics and constants must be known at compile time, and they live
213 for the entire lifetime of a program. Creating a boxed value allocates memory on
214 the heap at runtime, and therefore cannot be done at compile time. Erroneous
217 ```compile_fail,E0010
218 #![feature(box_syntax)]
220 const CON : Box<i32> = box 0;
225 Static and const variables can refer to other const variables. But a const
226 variable cannot refer to a static variable. For example, `Y` cannot refer to
229 ```compile_fail,E0013
234 To fix this, the value can be extracted as a const and then used:
243 // FIXME(#57563) Change the language here when const fn stabilizes
245 The only functions that can be called in static or constant expressions are
246 `const` functions, and struct/enum constructors. `const` functions are only
247 available on a nightly compiler. Rust currently does not support more general
248 compile-time function execution.
251 const FOO: Option<u8> = Some(1); // enum constructor
253 const BAR: Bar = Bar {x: 1}; // struct constructor
256 See [RFC 911] for more details on the design of `const fn`s.
258 [RFC 911]: https://github.com/rust-lang/rfcs/blob/master/text/0911-const-fn.md
262 References in statics and constants may only refer to immutable values.
263 Erroneous code example:
265 ```compile_fail,E0017
269 // these three are not allowed:
270 const CR: &mut i32 = &mut C;
271 static STATIC_REF: &'static mut i32 = &mut X;
272 static CONST_REF: &'static mut i32 = &mut C;
275 Statics are shared everywhere, and if they refer to mutable data one might
276 violate memory safety since holding multiple mutable references to shared data
279 If you really want global mutable state, try using `static mut` or a global
284 A function call isn't allowed in the const's initialization expression
285 because the expression's value must be known at compile-time. Erroneous code
294 fn test(&self) -> i32 {
300 const FOO: Test = Test::V1;
302 const A: i32 = FOO.test(); // You can't call Test::func() here!
306 Remember: you can't use a function call inside a const's initialization
307 expression! However, you can totally use it anywhere else:
315 fn func(&self) -> i32 {
321 const FOO: Test = Test::V1;
323 FOO.func(); // here is good
324 let x = FOO.func(); // or even here!
330 When matching against a range, the compiler verifies that the range is
331 non-empty. Range patterns include both end-points, so this is equivalent to
332 requiring the start of the range to be less than or equal to the end of the
339 // This range is ok, albeit pointless.
341 // This range is empty, and the compiler can tell.
348 Unsafe code was used outside of an unsafe function or block.
350 Erroneous code example:
352 ```compile_fail,E0133
353 unsafe fn f() { return; } // This is the unsafe code
356 f(); // error: call to unsafe function requires unsafe function or block
360 Using unsafe functionality is potentially dangerous and disallowed by safety
363 * Dereferencing raw pointers
364 * Calling functions via FFI
365 * Calling functions marked unsafe
367 These safety checks can be relaxed for a section of the code by wrapping the
368 unsafe instructions with an `unsafe` block. For instance:
371 unsafe fn f() { return; }
374 unsafe { f(); } // ok!
378 See also https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html
382 `const` and `static` mean different things. A `const` is a compile-time
383 constant, an alias for a literal value. This property means you can match it
384 directly within a pattern.
386 The `static` keyword, on the other hand, guarantees a fixed location in memory.
387 This does not always mean that the value is constant. For example, a global
388 mutex can be declared `static` as well.
390 If you want to match against a `static`, consider using a guard instead:
393 static FORTY_TWO: i32 = 42;
396 Some(x) if x == FORTY_TWO => {}
403 A value was moved. However, its size was not known at compile time, and only
404 values of a known size can be moved.
406 Erroneous code example:
409 #![feature(box_syntax)]
412 let array: &[isize] = &[1, 2, 3];
413 let _x: Box<[isize]> = box *array;
414 // error: cannot move a value of type [isize]: the size of [isize] cannot
415 // be statically determined
419 In Rust, you can only move a value when its size is known at compile time.
421 To work around this restriction, consider "hiding" the value behind a reference:
422 either `&x` or `&mut x`. Since a reference has a fixed size, this lets you move
423 it around as usual. Example:
426 #![feature(box_syntax)]
429 let array: &[isize] = &[1, 2, 3];
430 let _x: Box<&[isize]> = box array; // ok!
436 #### Note: this error code is no longer emitted by the compiler.
438 An if-let pattern attempts to match the pattern, and enters the body if the
439 match was successful. If the match is irrefutable (when it cannot fail to
440 match), use a regular `let`-binding instead. For instance:
443 struct Irrefutable(i32);
444 let irr = Irrefutable(0);
446 // This fails to compile because the match is irrefutable.
447 if let Irrefutable(x) = irr {
448 // This body will always be executed.
456 struct Irrefutable(i32);
457 let irr = Irrefutable(0);
459 let Irrefutable(x) = irr;
465 #### Note: this error code is no longer emitted by the compiler.
467 A while-let pattern attempts to match the pattern, and enters the body if the
468 match was successful. If the match is irrefutable (when it cannot fail to
469 match), use a regular `let`-binding inside a `loop` instead. For instance:
472 struct Irrefutable(i32);
473 let irr = Irrefutable(0);
475 // This fails to compile because the match is irrefutable.
476 while let Irrefutable(x) = irr {
484 struct Irrefutable(i32);
485 let irr = Irrefutable(0);
488 let Irrefutable(x) = irr;
495 Enum variants are qualified by default. For example, given this type:
504 You would match it using:
520 If you don't qualify the names, the code will bind new variables named "GET" and
521 "POST" instead. This behavior is likely not what you want, so `rustc` warns when
524 Qualified names are good practice, and most code works well with them. But if
525 you prefer them unqualified, you can import the variants into scope:
529 enum Method { GET, POST }
533 If you want others to be able to import variants from your module directly, use
538 pub enum Method { GET, POST }
545 #### Note: this error code is no longer emitted by the compiler.
547 Patterns used to bind names must be irrefutable. That is, they must guarantee
548 that a name will be extracted in all cases. Instead of pattern matching the
549 loop variable, consider using a `match` or `if let` inside the loop body. For
552 ```compile_fail,E0005
553 let xs : Vec<Option<i32>> = vec![Some(1), None];
555 // This fails because `None` is not covered.
561 Match inside the loop instead:
564 let xs : Vec<Option<i32>> = vec![Some(1), None];
577 let xs : Vec<Option<i32>> = vec![Some(1), None];
580 if let Some(x) = item {
588 #### Note: this error code is no longer emitted by the compiler.
590 Mutable borrows are not allowed in pattern guards, because matching cannot have
591 side effects. Side effects could alter the matched object or the environment
592 on which the match depends in such a way, that the match would not be
593 exhaustive. For instance, the following would not match any arm if mutable
594 borrows were allowed:
596 ```compile_fail,E0596
599 option if option.take().is_none() => {
600 /* impossible, option is `Some` */
602 Some(_) => { } // When the previous match failed, the option became `None`.
608 #### Note: this error code is no longer emitted by the compiler.
610 Assignments are not allowed in pattern guards, because matching cannot have
611 side effects. Side effects could alter the matched object or the environment
612 on which the match depends in such a way, that the match would not be
613 exhaustive. For instance, the following would not match any arm if assignments
616 ```compile_fail,E0594
619 option if { option = None; false } => { },
620 Some(_) => { } // When the previous match failed, the option became `None`.
626 In certain cases it is possible for sub-bindings to violate memory safety.
627 Updates to the borrow checker in a future version of Rust may remove this
628 restriction, but for now patterns must be rewritten without sub-bindings.
632 ```compile_fail,E0303
633 match Some("hi".to_string()) {
634 ref op_string_ref @ Some(s) => {},
642 match Some("hi".to_string()) {
644 let op_string_ref = &Some(s);
651 The `op_string_ref` binding has type `&Option<&String>` in both cases.
653 See also https://github.com/rust-lang/rust/issues/14587
657 This error occurs when an attempt is made to use data captured by a closure,
658 when that data may no longer exist. It's most commonly seen when attempting to
661 ```compile_fail,E0373
662 fn foo() -> Box<Fn(u32) -> u32> {
668 Notice that `x` is stack-allocated by `foo()`. By default, Rust captures
669 closed-over data by reference. This means that once `foo()` returns, `x` no
670 longer exists. An attempt to access `x` within the closure would thus be
673 Another situation where this might be encountered is when spawning threads:
675 ```compile_fail,E0373
680 let thr = std::thread::spawn(|| {
686 Since our new thread runs in parallel, the stack frame containing `x` and `y`
687 may well have disappeared by the time we try to use them. Even if we call
688 `thr.join()` within foo (which blocks until `thr` has completed, ensuring the
689 stack frame won't disappear), we will not succeed: the compiler cannot prove
690 that this behaviour is safe, and so won't let us do it.
692 The solution to this problem is usually to switch to using a `move` closure.
693 This approach moves (or copies, where possible) data into the closure, rather
694 than taking references to it. For example:
697 fn foo() -> Box<Fn(u32) -> u32> {
699 Box::new(move |y| x + y)
703 Now that the closure has its own copy of the data, there's no need to worry
708 It is not allowed to use or capture an uninitialized variable. For example:
710 ```compile_fail,E0381
713 let y = x; // error, use of possibly-uninitialized variable
717 To fix this, ensure that any declared variables are initialized before being
729 This error occurs when an attempt is made to use a variable after its contents
730 have been moved elsewhere. For example:
732 ```compile_fail,E0382
733 struct MyStruct { s: u32 }
736 let mut x = MyStruct{ s: 5u32 };
743 Since `MyStruct` is a type that is not marked `Copy`, the data gets moved out
744 of `x` when we set `y`. This is fundamental to Rust's ownership system: outside
745 of workarounds like `Rc`, a value cannot be owned by more than one variable.
747 Sometimes we don't need to move the value. Using a reference, we can let another
748 function borrow the value without changing its ownership. In the example below,
749 we don't actually have to move our string to `calculate_length`, we can give it
750 a reference to it with `&` instead.
754 let s1 = String::from("hello");
756 let len = calculate_length(&s1);
758 println!("The length of '{}' is {}.", s1, len);
761 fn calculate_length(s: &String) -> usize {
766 A mutable reference can be created with `&mut`.
768 Sometimes we don't want a reference, but a duplicate. All types marked `Clone`
769 can be duplicated by calling `.clone()`. Subsequent changes to a clone do not
770 affect the original variable.
772 Most types in the standard library are marked `Clone`. The example below
773 demonstrates using `clone()` on a string. `s1` is first set to "many", and then
774 copied to `s2`. Then the first character of `s1` is removed, without affecting
775 `s2`. "any many" is printed to the console.
779 let mut s1 = String::from("many");
782 println!("{} {}", s1, s2);
786 If we control the definition of a type, we can implement `Clone` on it ourselves
787 with `#[derive(Clone)]`.
789 Some types have no ownership semantics at all and are trivial to duplicate. An
790 example is `i32` and the other number types. We don't have to call `.clone()` to
791 clone them, because they are marked `Copy` in addition to `Clone`. Implicit
792 cloning is more convenient in this case. We can mark our own types `Copy` if
793 all their members also are marked `Copy`.
795 In the example below, we implement a `Point` type. Because it only stores two
796 integers, we opt-out of ownership semantics with `Copy`. Then we can
797 `let p2 = p1` without `p1` being moved.
800 #[derive(Copy, Clone)]
801 struct Point { x: i32, y: i32 }
804 let mut p1 = Point{ x: -1, y: 2 };
807 println!("p1: {}, {}", p1.x, p1.y);
808 println!("p2: {}, {}", p2.x, p2.y);
812 Alternatively, if we don't control the struct's definition, or mutable shared
813 ownership is truly required, we can use `Rc` and `RefCell`:
816 use std::cell::RefCell;
819 struct MyStruct { s: u32 }
822 let mut x = Rc::new(RefCell::new(MyStruct{ s: 5u32 }));
824 x.borrow_mut().s = 6;
825 println!("{}", x.borrow().s);
829 With this approach, x and y share ownership of the data via the `Rc` (reference
830 count type). `RefCell` essentially performs runtime borrow checking: ensuring
831 that at most one writer or multiple readers can access the data at any one time.
833 If you wish to learn more about ownership in Rust, start with the chapter in the
836 https://doc.rust-lang.org/book/ch04-00-understanding-ownership.html
840 #### Note: this error code is no longer emitted by the compiler.
842 This error occurs when an attempt is made to partially reinitialize a
843 structure that is currently uninitialized.
845 For example, this can happen when a drop has taken place:
852 fn drop(&mut self) { /* ... */ }
855 let mut x = Foo { a: 1 };
856 drop(x); // `x` is now uninitialized
857 x.a = 2; // error, partial reinitialization of uninitialized structure `t`
860 This error can be fixed by fully reinitializing the structure in question:
867 fn drop(&mut self) { /* ... */ }
870 let mut x = Foo { a: 1 };
877 This error occurs when an attempt is made to reassign an immutable variable.
879 Erroneous code example:
881 ```compile_fail,E0384
884 x = 5; // error, reassignment of immutable variable
888 By default, variables in Rust are immutable. To fix this error, add the keyword
889 `mut` after the keyword `let` when declaring the variable. For example:
900 #### Note: this error code is no longer emitted by the compiler.
902 This error occurs when an attempt is made to mutate the target of a mutable
903 reference stored inside an immutable container.
905 For example, this can happen when storing a `&mut` inside an immutable `Box`:
909 let y: Box<_> = Box::new(&mut x);
910 **y = 2; // error, cannot assign to data in an immutable container
913 This error can be fixed by making the container mutable:
917 let mut y: Box<_> = Box::new(&mut x);
921 It can also be fixed by using a type with interior mutability, such as `Cell`
928 let y: Box<Cell<_>> = Box::new(Cell::new(x));
934 #### Note: this error code is no longer emitted by the compiler.
936 This error occurs when an attempt is made to mutate or mutably reference data
937 that a closure has captured immutably. Examples of this error are shown below:
940 // Accepts a function or a closure that captures its environment immutably.
941 // Closures passed to foo will not be able to mutate their closed-over state.
942 fn foo<F: Fn()>(f: F) { }
944 // Attempts to mutate closed-over data. Error message reads:
945 // `cannot assign to data in a captured outer variable...`
951 // Attempts to take a mutable reference to closed-over data. Error message
952 // reads: `cannot borrow data mutably in a captured outer variable...`
955 foo(|| { let y = &mut x; });
959 The problem here is that foo is defined as accepting a parameter of type `Fn`.
960 Closures passed into foo will thus be inferred to be of type `Fn`, meaning that
961 they capture their context immutably.
963 If the definition of `foo` is under your control, the simplest solution is to
964 capture the data mutably. This can be done by defining `foo` to take FnMut
968 fn foo<F: FnMut()>(f: F) { }
971 Alternatively, we can consider using the `Cell` and `RefCell` types to achieve
972 interior mutability through a shared reference. Our example's `mutable`
973 function could be redefined as below:
978 fn foo<F: Fn()>(f: F) { }
981 let x = Cell::new(0u32);
986 You can read more about cell types in the API documentation:
988 https://doc.rust-lang.org/std/cell/
992 #### Note: this error code is no longer emitted by the compiler.
996 #### Note: this error code is no longer emitted by the compiler.
998 An attempt was made to mutate data using a non-mutable reference. This
999 commonly occurs when attempting to assign to a non-mutable reference of a
1000 mutable reference (`&(&mut T)`).
1002 Example of erroneous code:
1010 let mut fancy = FancyNum{ num: 5 };
1011 let fancy_ref = &(&mut fancy);
1012 fancy_ref.num = 6; // error: cannot assign to data in a `&` reference
1013 println!("{}", fancy_ref.num);
1017 Here, `&mut fancy` is mutable, but `&(&mut fancy)` is not. Creating an
1018 immutable reference to a value borrows it immutably. There can be multiple
1019 references of type `&(&mut T)` that point to the same value, so they must be
1020 immutable to prevent multiple mutable references to the same value.
1022 To fix this, either remove the outer reference:
1030 let mut fancy = FancyNum{ num: 5 };
1032 let fancy_ref = &mut fancy;
1033 // `fancy_ref` is now &mut FancyNum, rather than &(&mut FancyNum)
1035 fancy_ref.num = 6; // No error!
1037 println!("{}", fancy_ref.num);
1041 Or make the outer reference mutable:
1049 let mut fancy = FancyNum{ num: 5 };
1051 let fancy_ref = &mut (&mut fancy);
1052 // `fancy_ref` is now &mut(&mut FancyNum), rather than &(&mut FancyNum)
1054 fancy_ref.num = 6; // No error!
1056 println!("{}", fancy_ref.num);
1062 A borrow of a constant containing interior mutability was attempted. Erroneous
1065 ```compile_fail,E0492
1066 use std::sync::atomic::AtomicUsize;
1068 const A: AtomicUsize = AtomicUsize::new(0);
1069 static B: &'static AtomicUsize = &A;
1070 // error: cannot borrow a constant which may contain interior mutability,
1071 // create a static instead
1074 A `const` represents a constant value that should never change. If one takes
1075 a `&` reference to the constant, then one is taking a pointer to some memory
1076 location containing the value. Normally this is perfectly fine: most values
1077 can't be changed via a shared `&` pointer, but interior mutability would allow
1078 it. That is, a constant value could be mutated. On the other hand, a `static` is
1079 explicitly a single memory location, which can be mutated at will.
1081 So, in order to solve this error, either use statics which are `Sync`:
1084 use std::sync::atomic::AtomicUsize;
1086 static A: AtomicUsize = AtomicUsize::new(0);
1087 static B: &'static AtomicUsize = &A; // ok!
1090 You can also have this error while using a cell type:
1092 ```compile_fail,E0492
1093 use std::cell::Cell;
1095 const A: Cell<usize> = Cell::new(1);
1096 const B: &Cell<usize> = &A;
1097 // error: cannot borrow a constant which may contain interior mutability,
1098 // create a static instead
1101 struct C { a: Cell<usize> }
1103 const D: C = C { a: Cell::new(1) };
1104 const E: &Cell<usize> = &D.a; // error
1107 const F: &C = &D; // error
1110 This is because cell types do operations that are not thread-safe. Due to this,
1111 they don't implement Sync and thus can't be placed in statics.
1113 However, if you still wish to use these types, you can achieve this by an unsafe
1117 use std::cell::Cell;
1118 use std::marker::Sync;
1120 struct NotThreadSafe<T> {
1124 unsafe impl<T> Sync for NotThreadSafe<T> {}
1126 static A: NotThreadSafe<usize> = NotThreadSafe { value : Cell::new(1) };
1127 static B: &'static NotThreadSafe<usize> = &A; // ok!
1130 Remember this solution is unsafe! You will have to ensure that accesses to the
1131 cell are synchronized.
1135 A type with a `Drop` implementation was destructured when trying to initialize
1138 Erroneous code example:
1140 ```compile_fail,E0493
1145 impl Drop for DropType {
1146 fn drop(&mut self) {}
1153 static FOO: Foo = Foo { ..Foo { field1: DropType::A } }; // error!
1156 The problem here is that if the given type or one of its fields implements the
1157 `Drop` trait, this `Drop` implementation cannot be called during the static
1158 type initialization which might cause a memory leak. To prevent this issue,
1159 you need to instantiate all the static type's fields by hand.
1166 impl Drop for DropType {
1167 fn drop(&mut self) {}
1174 static FOO: Foo = Foo { field1: DropType::A }; // We initialize all fields
1180 A variable was borrowed as mutable more than once. Erroneous code example:
1182 ```compile_fail,E0499
1187 // error: cannot borrow `i` as mutable more than once at a time
1190 Please note that in rust, you can either have many immutable references, or one
1191 mutable reference. Take a look at
1192 https://doc.rust-lang.org/book/ch04-02-references-and-borrowing.html for more
1193 information. Example:
1198 let mut x = &mut i; // ok!
1203 let b = &i; // still ok!
1204 let c = &i; // still ok!
1211 A borrowed variable was used by a closure. Example of erroneous code:
1213 ```compile_fail,E0500
1214 fn you_know_nothing(jon_snow: &mut i32) {
1215 let nights_watch = &jon_snow;
1217 *jon_snow = 3; // error: closure requires unique access to `jon_snow`
1218 // but it is already borrowed
1220 println!("{}", nights_watch);
1224 In here, `jon_snow` is already borrowed by the `nights_watch` reference, so it
1225 cannot be borrowed by the `starks` closure at the same time. To fix this issue,
1226 you can create the closure after the borrow has ended:
1229 fn you_know_nothing(jon_snow: &mut i32) {
1230 let nights_watch = &jon_snow;
1231 println!("{}", nights_watch);
1238 Or, if the type implements the `Clone` trait, you can clone it between
1242 fn you_know_nothing(jon_snow: &mut i32) {
1243 let mut jon_copy = jon_snow.clone();
1247 println!("{}", jon_copy);
1253 This error indicates that a mutable variable is being used while it is still
1254 captured by a closure. Because the closure has borrowed the variable, it is not
1255 available for use until the closure goes out of scope.
1257 Note that a capture will either move or borrow a variable, but in this
1258 situation, the closure is borrowing the variable. Take a look at
1259 http://rustbyexample.com/fn/closures/capture.html for more information about
1262 Example of erroneous code:
1264 ```compile_fail,E0501
1265 fn inside_closure(x: &mut i32) {
1266 // Actions which require unique access
1269 fn outside_closure(x: &mut i32) {
1270 // Actions which require unique access
1273 fn foo(a: &mut i32) {
1277 outside_closure(a); // error: cannot borrow `*a` as mutable because previous
1278 // closure requires unique access.
1283 To fix this error, you can finish using the closure before using the captured
1287 fn inside_closure(x: &mut i32) {}
1288 fn outside_closure(x: &mut i32) {}
1290 fn foo(a: &mut i32) {
1295 // borrow on `a` ends.
1296 outside_closure(a); // ok!
1300 Or you can pass the variable as a parameter to the closure:
1303 fn inside_closure(x: &mut i32) {}
1304 fn outside_closure(x: &mut i32) {}
1306 fn foo(a: &mut i32) {
1307 let mut bar = |s: &mut i32| {
1315 It may be possible to define the closure later:
1318 fn inside_closure(x: &mut i32) {}
1319 fn outside_closure(x: &mut i32) {}
1321 fn foo(a: &mut i32) {
1332 This error indicates that you are trying to borrow a variable as mutable when it
1333 has already been borrowed as immutable.
1335 Example of erroneous code:
1337 ```compile_fail,E0502
1338 fn bar(x: &mut i32) {}
1339 fn foo(a: &mut i32) {
1340 let ref y = a; // a is borrowed as immutable.
1341 bar(a); // error: cannot borrow `*a` as mutable because `a` is also borrowed
1347 To fix this error, ensure that you don't have any other references to the
1348 variable before trying to access it mutably:
1351 fn bar(x: &mut i32) {}
1352 fn foo(a: &mut i32) {
1354 let ref y = a; // ok!
1359 For more information on the rust ownership system, take a look at
1360 https://doc.rust-lang.org/book/ch04-02-references-and-borrowing.html.
1364 A value was used after it was mutably borrowed.
1366 Example of erroneous code:
1368 ```compile_fail,E0503
1371 // Create a mutable borrow of `value`.
1372 let borrow = &mut value;
1373 let _sum = value + 1; // error: cannot use `value` because
1374 // it was mutably borrowed
1375 println!("{}", borrow);
1379 In this example, `value` is mutably borrowed by `borrow` and cannot be
1380 used to calculate `sum`. This is not possible because this would violate
1381 Rust's mutability rules.
1383 You can fix this error by finishing using the borrow before the next use of
1389 let borrow = &mut value;
1390 println!("{}", borrow);
1391 // The block has ended and with it the borrow.
1392 // You can now use `value` again.
1393 let _sum = value + 1;
1397 Or by cloning `value` before borrowing it:
1402 // We clone `value`, creating a copy.
1403 let value_cloned = value.clone();
1404 // The mutable borrow is a reference to `value` and
1405 // not to `value_cloned`...
1406 let borrow = &mut value;
1407 // ... which means we can still use `value_cloned`,
1408 let _sum = value_cloned + 1;
1409 // even though the borrow only ends here.
1410 println!("{}", borrow);
1414 You can find more information about borrowing in the rust-book:
1415 http://doc.rust-lang.org/book/ch04-02-references-and-borrowing.html
1419 #### Note: this error code is no longer emitted by the compiler.
1421 This error occurs when an attempt is made to move a borrowed variable into a
1424 Example of erroneous code:
1432 let fancy_num = FancyNum { num: 5 };
1433 let fancy_ref = &fancy_num;
1436 println!("child function: {}", fancy_num.num);
1437 // error: cannot move `fancy_num` into closure because it is borrowed
1441 println!("main function: {}", fancy_ref.num);
1445 Here, `fancy_num` is borrowed by `fancy_ref` and so cannot be moved into
1446 the closure `x`. There is no way to move a value into a closure while it is
1447 borrowed, as that would invalidate the borrow.
1449 If the closure can't outlive the value being moved, try using a reference
1458 let fancy_num = FancyNum { num: 5 };
1459 let fancy_ref = &fancy_num;
1462 // fancy_ref is usable here because it doesn't move `fancy_num`
1463 println!("child function: {}", fancy_ref.num);
1468 println!("main function: {}", fancy_num.num);
1472 If the value has to be borrowed and then moved, try limiting the lifetime of
1473 the borrow using a scoped block:
1481 let fancy_num = FancyNum { num: 5 };
1484 let fancy_ref = &fancy_num;
1485 println!("main function: {}", fancy_ref.num);
1486 // `fancy_ref` goes out of scope here
1490 // `fancy_num` can be moved now (no more references exist)
1491 println!("child function: {}", fancy_num.num);
1498 If the lifetime of a reference isn't enough, such as in the case of threading,
1499 consider using an `Arc` to create a reference-counted value:
1510 let fancy_ref1 = Arc::new(FancyNum { num: 5 });
1511 let fancy_ref2 = fancy_ref1.clone();
1513 let x = thread::spawn(move || {
1514 // `fancy_ref1` can be moved and has a `'static` lifetime
1515 println!("child thread: {}", fancy_ref1.num);
1518 x.join().expect("child thread should finish");
1519 println!("main thread: {}", fancy_ref2.num);
1525 A value was moved out while it was still borrowed.
1527 Erroneous code example:
1529 ```compile_fail,E0505
1532 fn borrow(val: &Value) {}
1534 fn eat(val: Value) {}
1538 let _ref_to_val: &Value = &x;
1540 borrow(_ref_to_val);
1544 Here, the function `eat` takes ownership of `x`. However,
1545 `x` cannot be moved because the borrow to `_ref_to_val`
1546 needs to last till the function `borrow`.
1547 To fix that you can do a few different things:
1549 * Try to avoid moving the variable.
1550 * Release borrow before move.
1551 * Implement the `Copy` trait on the type.
1558 fn borrow(val: &Value) {}
1560 fn eat(val: &Value) {}
1565 let ref_to_val: &Value = &x;
1566 eat(&x); // pass by reference, if it's possible
1576 fn borrow(val: &Value) {}
1578 fn eat(val: Value) {}
1583 let ref_to_val: &Value = &x;
1585 // ref_to_val is no longer used.
1593 #[derive(Clone, Copy)] // implement Copy trait
1596 fn borrow(val: &Value) {}
1598 fn eat(val: Value) {}
1602 let ref_to_val: &Value = &x;
1603 eat(x); // it will be copied here.
1608 You can find more information about borrowing in the rust-book:
1609 http://doc.rust-lang.org/book/ch04-02-references-and-borrowing.html
1613 This error occurs when an attempt is made to assign to a borrowed value.
1615 Example of erroneous code:
1617 ```compile_fail,E0506
1623 let mut fancy_num = FancyNum { num: 5 };
1624 let fancy_ref = &fancy_num;
1625 fancy_num = FancyNum { num: 6 };
1626 // error: cannot assign to `fancy_num` because it is borrowed
1628 println!("Num: {}, Ref: {}", fancy_num.num, fancy_ref.num);
1632 Because `fancy_ref` still holds a reference to `fancy_num`, `fancy_num` can't
1633 be assigned to a new value as it would invalidate the reference.
1635 Alternatively, we can move out of `fancy_num` into a second `fancy_num`:
1643 let mut fancy_num = FancyNum { num: 5 };
1644 let moved_num = fancy_num;
1645 fancy_num = FancyNum { num: 6 };
1647 println!("Num: {}, Moved num: {}", fancy_num.num, moved_num.num);
1651 If the value has to be borrowed, try limiting the lifetime of the borrow using
1660 let mut fancy_num = FancyNum { num: 5 };
1663 let fancy_ref = &fancy_num;
1664 println!("Ref: {}", fancy_ref.num);
1667 // Works because `fancy_ref` is no longer in scope
1668 fancy_num = FancyNum { num: 6 };
1669 println!("Num: {}", fancy_num.num);
1673 Or by moving the reference into a function:
1681 let mut fancy_num = FancyNum { num: 5 };
1683 print_fancy_ref(&fancy_num);
1685 // Works because function borrow has ended
1686 fancy_num = FancyNum { num: 6 };
1687 println!("Num: {}", fancy_num.num);
1690 fn print_fancy_ref(fancy_ref: &FancyNum){
1691 println!("Ref: {}", fancy_ref.num);
1697 You tried to move out of a value which was borrowed.
1699 This can also happen when using a type implementing `Fn` or `FnMut`, as neither
1700 allows moving out of them (they usually represent closures which can be called
1701 more than once). Much of the text following applies equally well to non-`FnOnce`
1704 Erroneous code example:
1706 ```compile_fail,E0507
1707 use std::cell::RefCell;
1709 struct TheDarkKnight;
1711 impl TheDarkKnight {
1712 fn nothing_is_true(self) {}
1716 let x = RefCell::new(TheDarkKnight);
1718 x.borrow().nothing_is_true(); // error: cannot move out of borrowed content
1722 Here, the `nothing_is_true` method takes the ownership of `self`. However,
1723 `self` cannot be moved because `.borrow()` only provides an `&TheDarkKnight`,
1724 which is a borrow of the content owned by the `RefCell`. To fix this error,
1725 you have three choices:
1727 * Try to avoid moving the variable.
1728 * Somehow reclaim the ownership.
1729 * Implement the `Copy` trait on the type.
1734 use std::cell::RefCell;
1736 struct TheDarkKnight;
1738 impl TheDarkKnight {
1739 fn nothing_is_true(&self) {} // First case, we don't take ownership
1743 let x = RefCell::new(TheDarkKnight);
1745 x.borrow().nothing_is_true(); // ok!
1752 use std::cell::RefCell;
1754 struct TheDarkKnight;
1756 impl TheDarkKnight {
1757 fn nothing_is_true(self) {}
1761 let x = RefCell::new(TheDarkKnight);
1762 let x = x.into_inner(); // we get back ownership
1764 x.nothing_is_true(); // ok!
1771 use std::cell::RefCell;
1773 #[derive(Clone, Copy)] // we implement the Copy trait
1774 struct TheDarkKnight;
1776 impl TheDarkKnight {
1777 fn nothing_is_true(self) {}
1781 let x = RefCell::new(TheDarkKnight);
1783 x.borrow().nothing_is_true(); // ok!
1787 Moving a member out of a mutably borrowed struct will also cause E0507 error:
1789 ```compile_fail,E0507
1790 struct TheDarkKnight;
1792 impl TheDarkKnight {
1793 fn nothing_is_true(self) {}
1797 knight: TheDarkKnight
1801 let mut cave = Batcave {
1802 knight: TheDarkKnight
1804 let borrowed = &mut cave;
1806 borrowed.knight.nothing_is_true(); // E0507
1810 It is fine only if you put something back. `mem::replace` can be used for that:
1813 # struct TheDarkKnight;
1814 # impl TheDarkKnight { fn nothing_is_true(self) {} }
1815 # struct Batcave { knight: TheDarkKnight }
1818 let mut cave = Batcave {
1819 knight: TheDarkKnight
1821 let borrowed = &mut cave;
1823 mem::replace(&mut borrowed.knight, TheDarkKnight).nothing_is_true(); // ok!
1826 You can find more information about borrowing in the rust-book:
1827 http://doc.rust-lang.org/book/ch04-02-references-and-borrowing.html
1831 A value was moved out of a non-copy fixed-size array.
1833 Example of erroneous code:
1835 ```compile_fail,E0508
1839 let array = [NonCopy; 1];
1840 let _value = array[0]; // error: cannot move out of type `[NonCopy; 1]`,
1841 // a non-copy fixed-size array
1845 The first element was moved out of the array, but this is not
1846 possible because `NonCopy` does not implement the `Copy` trait.
1848 Consider borrowing the element instead of moving it:
1854 let array = [NonCopy; 1];
1855 let _value = &array[0]; // Borrowing is allowed, unlike moving.
1859 Alternatively, if your type implements `Clone` and you need to own the value,
1860 consider borrowing and then cloning:
1867 let array = [NonCopy; 1];
1868 // Now you can clone the array element.
1869 let _value = array[0].clone();
1875 This error occurs when an attempt is made to move out of a value whose type
1876 implements the `Drop` trait.
1878 Example of erroneous code:
1880 ```compile_fail,E0509
1889 impl Drop for DropStruct {
1890 fn drop(&mut self) {
1891 // Destruct DropStruct, possibly using FancyNum
1896 let drop_struct = DropStruct{fancy: FancyNum{num: 5}};
1897 let fancy_field = drop_struct.fancy; // Error E0509
1898 println!("Fancy: {}", fancy_field.num);
1899 // implicit call to `drop_struct.drop()` as drop_struct goes out of scope
1903 Here, we tried to move a field out of a struct of type `DropStruct` which
1904 implements the `Drop` trait. However, a struct cannot be dropped if one or
1905 more of its fields have been moved.
1907 Structs implementing the `Drop` trait have an implicit destructor that gets
1908 called when they go out of scope. This destructor may use the fields of the
1909 struct, so moving out of the struct could make it impossible to run the
1910 destructor. Therefore, we must think of all values whose type implements the
1911 `Drop` trait as single units whose fields cannot be moved.
1913 This error can be fixed by creating a reference to the fields of a struct,
1914 enum, or tuple using the `ref` keyword:
1925 impl Drop for DropStruct {
1926 fn drop(&mut self) {
1927 // Destruct DropStruct, possibly using FancyNum
1932 let drop_struct = DropStruct{fancy: FancyNum{num: 5}};
1933 let ref fancy_field = drop_struct.fancy; // No more errors!
1934 println!("Fancy: {}", fancy_field.num);
1935 // implicit call to `drop_struct.drop()` as drop_struct goes out of scope
1939 Note that this technique can also be used in the arms of a match expression:
1950 impl Drop for DropEnum {
1951 fn drop(&mut self) {
1952 // Destruct DropEnum, possibly using FancyNum
1957 // Creates and enum of type `DropEnum`, which implements `Drop`
1958 let drop_enum = DropEnum::Fancy(FancyNum{num: 10});
1960 // Creates a reference to the inside of `DropEnum::Fancy`
1961 DropEnum::Fancy(ref fancy_field) => // No error!
1962 println!("It was fancy-- {}!", fancy_field.num),
1964 // implicit call to `drop_enum.drop()` as drop_enum goes out of scope
1970 Cannot mutate place in this match guard.
1972 When matching on a variable it cannot be mutated in the match guards, as this
1973 could cause the match to be non-exhaustive:
1975 ```compile_fail,E0510
1976 let mut x = Some(0);
1979 Some(_) if { x = None; false } => (),
1980 Some(v) => (), // No longer matches
1984 Here executing `x = None` would modify the value being matched and require us
1985 to go "back in time" to the `None` arm.
1989 Cannot return value that references local variable
1991 Local variables, function parameters and temporaries are all dropped before the
1992 end of the function body. So a reference to them cannot be returned.
1994 ```compile_fail,E0515
1995 fn get_dangling_reference() -> &'static i32 {
2001 ```compile_fail,E0515
2002 use std::slice::Iter;
2003 fn get_dangling_iterator<'a>() -> Iter<'a, i32> {
2004 let v = vec![1, 2, 3];
2009 Consider returning an owned value instead:
2012 use std::vec::IntoIter;
2014 fn get_integer() -> i32 {
2019 fn get_owned_iterator() -> IntoIter<i32> {
2020 let v = vec![1, 2, 3];
2027 A variable which requires unique access is being used in more than one closure
2030 Erroneous code example:
2032 ```compile_fail,E0524
2033 fn set(x: &mut isize) {
2037 fn dragoooon(x: &mut isize) {
2038 let mut c1 = || set(x);
2039 let mut c2 = || set(x); // error!
2046 To solve this issue, multiple solutions are available. First, is it required
2047 for this variable to be used in more than one closure at a time? If it is the
2048 case, use reference counted types such as `Rc` (or `Arc` if it runs
2053 use std::cell::RefCell;
2055 fn set(x: &mut isize) {
2059 fn dragoooon(x: &mut isize) {
2060 let x = Rc::new(RefCell::new(x));
2061 let y = Rc::clone(&x);
2062 let mut c1 = || { let mut x2 = x.borrow_mut(); set(&mut x2); };
2063 let mut c2 = || { let mut x2 = y.borrow_mut(); set(&mut x2); }; // ok!
2070 If not, just run closures one at a time:
2073 fn set(x: &mut isize) {
2077 fn dragoooon(x: &mut isize) {
2078 { // This block isn't necessary since non-lexical lifetimes, it's just to
2079 // make it more clear.
2080 let mut c1 = || set(&mut *x);
2082 } // `c1` has been dropped here so we're free to use `x` again!
2083 let mut c2 = || set(&mut *x);
2090 When matching against an exclusive range, the compiler verifies that the range
2091 is non-empty. Exclusive range patterns include the start point but not the end
2092 point, so this is equivalent to requiring the start of the range to be less
2093 than the end of the range.
2099 // This range is ok, albeit pointless.
2101 // This range is empty, and the compiler can tell.
2108 #### Note: this error code is no longer emitted by the compiler.
2110 Closures cannot mutate immutable captured variables.
2112 Erroneous code example:
2114 ```compile_fail,E0594
2115 let x = 3; // error: closure cannot assign to immutable local variable `x`
2116 let mut c = || { x += 1 };
2119 Make the variable binding mutable:
2122 let mut x = 3; // ok!
2123 let mut c = || { x += 1 };
2128 This error occurs because you tried to mutably borrow a non-mutable variable.
2130 Example of erroneous code:
2132 ```compile_fail,E0596
2134 let y = &mut x; // error: cannot borrow mutably
2137 In here, `x` isn't mutable, so when we try to mutably borrow it in `y`, it
2138 fails. To fix this error, you need to make `x` mutable:
2142 let y = &mut x; // ok!
2147 This error occurs because a value was dropped while it was still borrowed
2149 Example of erroneous code:
2151 ```compile_fail,E0597
2156 let mut x = Foo { x: None };
2159 x.x = Some(&y); // error: `y` does not live long enough
2161 println!("{:?}", x.x);
2164 In here, `y` is dropped at the end of the inner scope, but it is borrowed by
2165 `x` until the `println`. To fix the previous example, just remove the scope
2166 so that `y` isn't dropped until after the println
2173 let mut x = Foo { x: None };
2178 println!("{:?}", x.x);
2183 This error occurs because a borrow in a generator persists across a
2186 ```compile_fail,E0626
2187 # #![feature(generators, generator_trait, pin)]
2188 # use std::ops::Generator;
2189 # use std::pin::Pin;
2191 let a = &String::new(); // <-- This borrow...
2192 yield (); // ...is still in scope here, when the yield occurs.
2195 Pin::new(&mut b).resume();
2198 At present, it is not permitted to have a yield that occurs while a
2199 borrow is still in scope. To resolve this error, the borrow must
2200 either be "contained" to a smaller scope that does not overlap the
2201 yield or else eliminated in another way. So, for example, we might
2202 resolve the previous example by removing the borrow and just storing
2203 the integer by value:
2206 # #![feature(generators, generator_trait, pin)]
2207 # use std::ops::Generator;
2208 # use std::pin::Pin;
2214 Pin::new(&mut b).resume();
2217 This is a very simple case, of course. In more complex cases, we may
2218 wish to have more than one reference to the value that was borrowed --
2219 in those cases, something like the `Rc` or `Arc` types may be useful.
2221 This error also frequently arises with iteration:
2223 ```compile_fail,E0626
2224 # #![feature(generators, generator_trait, pin)]
2225 # use std::ops::Generator;
2226 # use std::pin::Pin;
2228 let v = vec![1,2,3];
2229 for &x in &v { // <-- borrow of `v` is still in scope...
2230 yield x; // ...when this yield occurs.
2233 Pin::new(&mut b).resume();
2236 Such cases can sometimes be resolved by iterating "by value" (or using
2237 `into_iter()`) to avoid borrowing:
2240 # #![feature(generators, generator_trait, pin)]
2241 # use std::ops::Generator;
2242 # use std::pin::Pin;
2244 let v = vec![1,2,3];
2245 for x in v { // <-- Take ownership of the values instead!
2246 yield x; // <-- Now yield is OK.
2249 Pin::new(&mut b).resume();
2252 If taking ownership is not an option, using indices can work too:
2255 # #![feature(generators, generator_trait, pin)]
2256 # use std::ops::Generator;
2257 # use std::pin::Pin;
2259 let v = vec![1,2,3];
2260 let len = v.len(); // (*)
2262 let x = v[i]; // (*)
2263 yield x; // <-- Now yield is OK.
2266 Pin::new(&mut b).resume();
2268 // (*) -- Unfortunately, these temporaries are currently required.
2269 // See <https://github.com/rust-lang/rust/issues/43122>.
2274 This error occurs because a borrow of a thread-local variable was made inside a
2275 function which outlived the lifetime of the function.
2277 Example of erroneous code:
2279 ```compile_fail,E0712
2280 #![feature(thread_local)]
2286 let a = &FOO; // error: thread-local variable borrowed past end of function
2288 std::thread::spawn(move || {
2296 This error occurs when an attempt is made to borrow state past the end of the
2297 lifetime of a type that implements the `Drop` trait.
2299 Example of erroneous code:
2301 ```compile_fail,E0713
2304 pub struct S<'a> { data: &'a mut String }
2306 impl<'a> Drop for S<'a> {
2307 fn drop(&mut self) { self.data.push_str("being dropped"); }
2310 fn demo<'a>(s: S<'a>) -> &'a mut String { let p = &mut *s.data; p }
2313 Here, `demo` tries to borrow the string data held within its
2314 argument `s` and then return that borrow. However, `S` is
2315 declared as implementing `Drop`.
2317 Structs implementing the `Drop` trait have an implicit destructor that
2318 gets called when they go out of scope. This destructor gets exclusive
2319 access to the fields of the struct when it runs.
2321 This means that when `s` reaches the end of `demo`, its destructor
2322 gets exclusive access to its `&mut`-borrowed string data. allowing
2323 another borrow of that string data (`p`), to exist across the drop of
2324 `s` would be a violation of the principle that `&mut`-borrows have
2325 exclusive, unaliased access to their referenced data.
2327 This error can be fixed by changing `demo` so that the destructor does
2328 not run while the string-data is borrowed; for example by taking `S`
2332 pub struct S<'a> { data: &'a mut String }
2334 impl<'a> Drop for S<'a> {
2335 fn drop(&mut self) { self.data.push_str("being dropped"); }
2338 fn demo<'a>(s: &'a mut S<'a>) -> &'a mut String { let p = &mut *(*s).data; p }
2341 Note that this approach needs a reference to S with lifetime `'a`.
2342 Nothing shorter than `'a` will suffice: a shorter lifetime would imply
2343 that after `demo` finishes executing, something else (such as the
2344 destructor!) could access `s.data` after the end of that shorter
2345 lifetime, which would again violate the `&mut`-borrow's exclusive
2350 This error indicates that a temporary value is being dropped
2351 while a borrow is still in active use.
2353 Erroneous code example:
2355 ```compile_fail,E0716
2356 fn foo() -> i32 { 22 }
2357 fn bar(x: &i32) -> &i32 { x }
2358 let p = bar(&foo());
2359 // ------ creates a temporary
2363 Here, the expression `&foo()` is borrowing the expression
2364 `foo()`. As `foo()` is a call to a function, and not the name of
2365 a variable, this creates a **temporary** -- that temporary stores
2366 the return value from `foo()` so that it can be borrowed.
2367 You could imagine that `let p = bar(&foo());` is equivalent
2370 ```compile_fail,E0597
2371 # fn foo() -> i32 { 22 }
2372 # fn bar(x: &i32) -> &i32 { x }
2374 let tmp = foo(); // the temporary
2376 }; // <-- tmp is freed as we exit this block
2380 Whenever a temporary is created, it is automatically dropped (freed)
2381 according to fixed rules. Ordinarily, the temporary is dropped
2382 at the end of the enclosing statement -- in this case, after the `let`.
2383 This is illustrated in the example above by showing that `tmp` would
2384 be freed as we exit the block.
2386 To fix this problem, you need to create a local variable
2387 to store the value in rather than relying on a temporary.
2388 For example, you might change the original program to
2392 fn foo() -> i32 { 22 }
2393 fn bar(x: &i32) -> &i32 { x }
2394 let value = foo(); // dropped at the end of the enclosing block
2395 let p = bar(&value);
2399 By introducing the explicit `let value`, we allocate storage
2400 that will last until the end of the enclosing block (when `value`
2401 goes out of scope). When we borrow `&value`, we are borrowing a
2402 local variable that already exists, and hence no temporary is created.
2404 Temporaries are not always dropped at the end of the enclosing
2405 statement. In simple cases where the `&` expression is immediately
2406 stored into a variable, the compiler will automatically extend
2407 the lifetime of the temporary until the end of the enclosing
2408 block. Therefore, an alternative way to fix the original
2409 program is to write `let tmp = &foo()` and not `let tmp = foo()`:
2412 fn foo() -> i32 { 22 }
2413 fn bar(x: &i32) -> &i32 { x }
2419 Here, we are still borrowing `foo()`, but as the borrow is assigned
2420 directly into a variable, the temporary will not be dropped until
2421 the end of the enclosing block. Similar rules apply when temporaries
2422 are stored into aggregate structures like a tuple or struct:
2425 // Here, two temporaries are created, but
2426 // as they are stored directly into `value`,
2427 // they are not dropped until the end of the
2429 fn foo() -> i32 { 22 }
2430 let value = (&foo(), &foo());
2435 An feature unstable in `const` contexts was used.
2437 Erroneous code example:
2439 ```compile_fail,E0723
2444 const fn foo() -> impl T { // error: `impl Trait` in const fn is unstable
2449 To enable this feature on a nightly version of rustc, add the `const_fn`
2453 #![feature(const_fn)]
2459 const fn foo() -> impl T {
2466 Support for Non-Lexical Lifetimes (NLL) has been included in the Rust compiler
2467 since 1.31, and has been enabled on the 2015 edition since 1.36. The new borrow
2468 checker for NLL uncovered some bugs in the old borrow checker, which in some
2469 cases allowed unsound code to compile, resulting in memory safety issues.
2473 Change your code so the warning does no longer trigger. For backwards
2474 compatibility, this unsound code may still compile (with a warning) right now.
2475 However, at some point in the future, the compiler will no longer accept this
2476 code and will throw a hard error.
2478 ### Shouldn't you fix the old borrow checker?
2480 The old borrow checker has known soundness issues that are basically impossible
2481 to fix. The new NLL-based borrow checker is the fix.
2483 ### Can I turn these warnings into errors by denying a lint?
2487 ### When are these warnings going to turn into errors?
2489 No formal timeline for turning the warnings into errors has been set. See
2490 [GitHub issue 58781](https://github.com/rust-lang/rust/issues/58781) for more
2493 ### Why do I get this message with code that doesn't involve borrowing?
2495 There are some known bugs that trigger this message.
2500 // E0008, // cannot bind by-move into a pattern guard
2501 // E0298, // cannot compare constants
2502 // E0299, // mismatched types between arms
2503 // E0471, // constant evaluation error (in pattern)
2504 // E0385, // {} in an aliasable location
2505 E0521, // borrowed data escapes outside of closure
2506 E0526, // shuffle indices are not constant
2507 E0594, // cannot assign to {}
2508 // E0598, // lifetime of {} is too short to guarantee its contents can be...
2509 E0625, // thread-local statics cannot be accessed at compile-time