1 // Error messages for EXXXX errors.
2 // Each message should start and end with a new line, and be wrapped to 80
3 // characters. In vim you can `:set tw=80` and use `gq` to wrap paragraphs. Use
4 // `:set tw=0` to disable.
5 syntax::register_diagnostics! {
7 Trait objects like `Box<Trait>` can only be constructed when certain
8 requirements are satisfied by the trait in question.
10 Trait objects are a form of dynamic dispatch and use a dynamically sized type
11 for the inner type. So, for a given trait `Trait`, when `Trait` is treated as a
12 type, as in `Box<Trait>`, the inner type is 'unsized'. In such cases the boxed
13 pointer is a 'fat pointer' that contains an extra pointer to a table of methods
14 (among other things) for dynamic dispatch. This design mandates some
15 restrictions on the types of traits that are allowed to be used in trait
16 objects, which are collectively termed as 'object safety' rules.
18 Attempting to create a trait object for a non object-safe trait will trigger
21 There are various rules:
23 ### The trait cannot require `Self: Sized`
25 When `Trait` is treated as a type, the type does not implement the special
26 `Sized` trait, because the type does not have a known size at compile time and
27 can only be accessed behind a pointer. Thus, if we have a trait like the
31 trait Foo where Self: Sized {
36 We cannot create an object of type `Box<Foo>` or `&Foo` since in this case
37 `Self` would not be `Sized`.
39 Generally, `Self: Sized` is used to indicate that the trait should not be used
40 as a trait object. If the trait comes from your own crate, consider removing
43 ### Method references the `Self` type in its parameters or return type
45 This happens when a trait has a method like the following:
49 fn foo(&self) -> Self;
52 impl Trait for String {
53 fn foo(&self) -> Self {
59 fn foo(&self) -> Self {
65 (Note that `&self` and `&mut self` are okay, it's additional `Self` types which
68 In such a case, the compiler cannot predict the return type of `foo()` in a
69 situation like the following:
73 fn foo(&self) -> Self;
76 fn call_foo(x: Box<Trait>) {
77 let y = x.foo(); // What type is y?
82 If only some methods aren't object-safe, you can add a `where Self: Sized` bound
83 on them to mark them as explicitly unavailable to trait objects. The
84 functionality will still be available to all other implementers, including
85 `Box<Trait>` which is itself sized (assuming you `impl Trait for Box<Trait>`).
89 fn foo(&self) -> Self where Self: Sized;
94 Now, `foo()` can no longer be called on a trait object, but you will now be
95 allowed to make a trait object, and that will be able to call any object-safe
96 methods. With such a bound, one can still call `foo()` on types implementing
97 that trait that aren't behind trait objects.
99 ### Method has generic type parameters
101 As mentioned before, trait objects contain pointers to method tables. So, if we
109 impl Trait for String {
123 At compile time each implementation of `Trait` will produce a table containing
124 the various methods (and other items) related to the implementation.
126 This works fine, but when the method gains generic parameters, we can have a
129 Usually, generic parameters get _monomorphized_. For example, if I have
137 The machine code for `foo::<u8>()`, `foo::<bool>()`, `foo::<String>()`, or any
138 other type substitution is different. Hence the compiler generates the
139 implementation on-demand. If you call `foo()` with a `bool` parameter, the
140 compiler will only generate code for `foo::<bool>()`. When we have additional
141 type parameters, the number of monomorphized implementations the compiler
142 generates does not grow drastically, since the compiler will only generate an
143 implementation if the function is called with unparametrized substitutions
144 (i.e., substitutions where none of the substituted types are themselves
147 However, with trait objects we have to make a table containing _every_ object
148 that implements the trait. Now, if it has type parameters, we need to add
149 implementations for every type that implements the trait, and there could
150 theoretically be an infinite number of types.
156 fn foo<T>(&self, on: T);
160 impl Trait for String {
161 fn foo<T>(&self, on: T) {
167 fn foo<T>(&self, on: T) {
172 // 8 more implementations
175 Now, if we have the following code:
177 ```compile_fail,E0038
178 # trait Trait { fn foo<T>(&self, on: T); }
179 # impl Trait for String { fn foo<T>(&self, on: T) {} }
180 # impl Trait for u8 { fn foo<T>(&self, on: T) {} }
181 # impl Trait for bool { fn foo<T>(&self, on: T) {} }
183 fn call_foo(thing: Box<Trait>) {
184 thing.foo(true); // this could be any one of the 8 types above
190 We don't just need to create a table of all implementations of all methods of
191 `Trait`, we need to create such a table, for each different type fed to
192 `foo()`. In this case this turns out to be (10 types implementing `Trait`)*(3
193 types being fed to `foo()`) = 30 implementations!
195 With real world traits these numbers can grow drastically.
197 To fix this, it is suggested to use a `where Self: Sized` bound similar to the
198 fix for the sub-error above if you do not intend to call the method with type
203 fn foo<T>(&self, on: T) where Self: Sized;
208 If this is not an option, consider replacing the type parameter with another
209 trait object (e.g., if `T: OtherTrait`, use `on: Box<OtherTrait>`). If the
210 number of types you intend to feed to this method is limited, consider manually
211 listing out the methods of different types.
213 ### Method has no receiver
215 Methods that do not take a `self` parameter can't be called since there won't be
216 a way to get a pointer to the method table for them.
224 This could be called as `<Foo as Foo>::foo()`, which would not be able to pick
227 Adding a `Self: Sized` bound to these methods will generally make this compile.
231 fn foo() -> u8 where Self: Sized;
235 ### The trait cannot contain associated constants
237 Just like static functions, associated constants aren't stored on the method
238 table. If the trait or any subtrait contain an associated constant, they cannot
239 be made into an object.
241 ```compile_fail,E0038
249 A simple workaround is to use a helper method instead:
257 ### The trait cannot use `Self` as a type parameter in the supertrait listing
259 This is similar to the second sub-error, but subtler. It happens in situations
262 ```compile_fail,E0038
263 trait Super<A: ?Sized> {}
265 trait Trait: Super<Self> {
270 impl Super<Foo> for Foo{}
272 impl Trait for Foo {}
275 let x: Box<dyn Trait>;
279 Here, the supertrait might have methods as follows:
282 trait Super<A: ?Sized> {
283 fn get_a(&self) -> &A; // note that this is object safe!
287 If the trait `Trait` was deriving from something like `Super<String>` or
288 `Super<T>` (where `Foo` itself is `Foo<T>`), this is okay, because given a type
289 `get_a()` will definitely return an object of that type.
291 However, if it derives from `Super<Self>`, even though `Super` is object safe,
292 the method `get_a()` would return an object of unknown type when called on the
293 function. `Self` type parameters let us make object safe traits no longer safe,
294 so they are forbidden when specifying supertraits.
296 There's no easy fix for this, generally code will need to be refactored so that
297 you no longer need to derive from `Super<Self>`.
301 When defining a recursive struct or enum, any use of the type being defined
302 from inside the definition must occur behind a pointer (like `Box` or `&`).
303 This is because structs and enums must have a well-defined size, and without
304 the pointer, the size of the type would need to be unbounded.
306 Consider the following erroneous definition of a type for a list of bytes:
308 ```compile_fail,E0072
309 // error, invalid recursive struct type
312 tail: Option<ListNode>,
316 This type cannot have a well-defined size, because it needs to be arbitrarily
317 large (since we would be able to nest `ListNode`s to any depth). Specifically,
320 size of `ListNode` = 1 byte for `head`
321 + 1 byte for the discriminant of the `Option`
325 One way to fix this is by wrapping `ListNode` in a `Box`, like so:
330 tail: Option<Box<ListNode>>,
334 This works because `Box` is a pointer, so its size is well-known.
338 This error indicates that the compiler was unable to sensibly evaluate an
339 constant expression that had to be evaluated. Attempting to divide by 0
340 or causing integer overflow are two ways to induce this error. For example:
342 ```compile_fail,E0080
349 Ensure that the expressions given can be evaluated as the desired integer type.
350 See the FFI section of the Reference for more information about using a custom
353 https://doc.rust-lang.org/reference.html#ffi-attributes
357 This error indicates that a lifetime is missing from a type. If it is an error
358 inside a function signature, the problem may be with failing to adhere to the
359 lifetime elision rules (see below).
361 Here are some simple examples of where you'll run into this error:
363 ```compile_fail,E0106
364 struct Foo1 { x: &bool }
365 // ^ expected lifetime parameter
366 struct Foo2<'a> { x: &'a bool } // correct
368 struct Bar1 { x: Foo2 }
369 // ^^^^ expected lifetime parameter
370 struct Bar2<'a> { x: Foo2<'a> } // correct
372 enum Baz1 { A(u8), B(&bool), }
373 // ^ expected lifetime parameter
374 enum Baz2<'a> { A(u8), B(&'a bool), } // correct
377 // ^ expected lifetime parameter
378 type MyStr2<'a> = &'a str; // correct
381 Lifetime elision is a special, limited kind of inference for lifetimes in
382 function signatures which allows you to leave out lifetimes in certain cases.
383 For more background on lifetime elision see [the book][book-le].
385 The lifetime elision rules require that any function signature with an elided
386 output lifetime must either have
388 - exactly one input lifetime
389 - or, multiple input lifetimes, but the function must also be a method with a
390 `&self` or `&mut self` receiver
392 In the first case, the output lifetime is inferred to be the same as the unique
393 input lifetime. In the second case, the lifetime is instead inferred to be the
394 same as the lifetime on `&self` or `&mut self`.
396 Here are some examples of elision errors:
398 ```compile_fail,E0106
399 // error, no input lifetimes
402 // error, `x` and `y` have distinct lifetimes inferred
403 fn bar(x: &str, y: &str) -> &str { }
405 // error, `y`'s lifetime is inferred to be distinct from `x`'s
406 fn baz<'a>(x: &'a str, y: &str) -> &str { }
409 [book-le]: https://doc.rust-lang.org/book/ch10-03-lifetime-syntax.html#lifetime-elision
413 There are conflicting trait implementations for the same type.
414 Example of erroneous code:
416 ```compile_fail,E0119
418 fn get(&self) -> usize;
421 impl<T> MyTrait for T {
422 fn get(&self) -> usize { 0 }
429 impl MyTrait for Foo { // error: conflicting implementations of trait
430 // `MyTrait` for type `Foo`
431 fn get(&self) -> usize { self.value }
435 When looking for the implementation for the trait, the compiler finds
436 both the `impl<T> MyTrait for T` where T is all types and the `impl
437 MyTrait for Foo`. Since a trait cannot be implemented multiple times,
438 this is an error. So, when you write:
442 fn get(&self) -> usize;
445 impl<T> MyTrait for T {
446 fn get(&self) -> usize { 0 }
450 This makes the trait implemented on all types in the scope. So if you
451 try to implement it on another one after that, the implementations will
456 fn get(&self) -> usize;
459 impl<T> MyTrait for T {
460 fn get(&self) -> usize { 0 }
468 f.get(); // the trait is implemented so we can use it
474 #### Note: this error code is no longer emitted by the compiler.
476 There are various restrictions on transmuting between types in Rust; for example
477 types being transmuted must have the same size. To apply all these restrictions,
478 the compiler must know the exact types that may be transmuted. When type
479 parameters are involved, this cannot always be done.
481 So, for example, the following is not allowed:
484 use std::mem::transmute;
486 struct Foo<T>(Vec<T>);
488 fn foo<T>(x: Vec<T>) {
489 // we are transmuting between Vec<T> and Foo<F> here
490 let y: Foo<T> = unsafe { transmute(x) };
491 // do something with y
495 In this specific case there's a good chance that the transmute is harmless (but
496 this is not guaranteed by Rust). However, when alignment and enum optimizations
497 come into the picture, it's quite likely that the sizes may or may not match
498 with different type parameter substitutions. It's not possible to check this for
499 _all_ possible types, so `transmute()` simply only accepts types without any
500 unsubstituted type parameters.
502 If you need this, there's a good chance you're doing something wrong. Keep in
503 mind that Rust doesn't guarantee much about the layout of different structs
504 (even two structs with identical declarations may have different layouts). If
505 there is a solution that avoids the transmute entirely, try it instead.
507 If it's possible, hand-monomorphize the code by writing the function for each
508 possible type substitution. It's possible to use traits to do this cleanly,
512 use std::mem::transmute;
514 struct Foo<T>(Vec<T>);
516 trait MyTransmutableType: Sized {
517 fn transmute(_: Vec<Self>) -> Foo<Self>;
520 impl MyTransmutableType for u8 {
521 fn transmute(x: Vec<u8>) -> Foo<u8> {
522 unsafe { transmute(x) }
526 impl MyTransmutableType for String {
527 fn transmute(x: Vec<String>) -> Foo<String> {
528 unsafe { transmute(x) }
532 // ... more impls for the types you intend to transmute
534 fn foo<T: MyTransmutableType>(x: Vec<T>) {
535 let y: Foo<T> = <T as MyTransmutableType>::transmute(x);
536 // do something with y
540 Each impl will be checked for a size match in the transmute as usual, and since
541 there are no unbound type parameters involved, this should compile unless there
542 is a size mismatch in one of the impls.
544 It is also possible to manually transmute:
548 # let v = Some("value");
549 # type SomeType = &'static [u8];
551 ptr::read(&v as *const _ as *const SomeType) // `v` transmuted to `SomeType`
556 Note that this does not move `v` (unlike `transmute`), and may need a
557 call to `mem::forget(v)` in case you want to avoid destructors being called.
561 A lang item was redefined.
563 Erroneous code example:
565 ```compile_fail,E0152
566 #![feature(lang_items)]
569 struct Foo; // error: duplicate lang item found: `arc`
572 Lang items are already implemented in the standard library. Unless you are
573 writing a free-standing application (e.g., a kernel), you do not need to provide
576 You can build a free-standing crate by adding `#![no_std]` to the crate
579 ```ignore (only-for-syntax-highlight)
583 See also the [unstable book][1].
585 [1]: https://doc.rust-lang.org/unstable-book/language-features/lang-items.html#writing-an-executable-without-stdlib
589 A generic type was described using parentheses rather than angle brackets.
592 ```compile_fail,E0214
594 let v: Vec(&str) = vec!["foo"];
598 This is not currently supported: `v` should be defined as `Vec<&str>`.
599 Parentheses are currently only used with generic types when defining parameters
600 for `Fn`-family traits.
604 The `#[rustc_on_unimplemented]` attribute lets you specify a custom error
605 message for when a particular trait isn't implemented on a type placed in a
606 position that needs that trait. For example, when the following code is
610 #![feature(on_unimplemented)]
612 fn foo<T: Index<u8>>(x: T){}
614 #[rustc_on_unimplemented = "the type `{Self}` cannot be indexed by `{Idx}`"]
615 trait Index<Idx> { /* ... */ }
617 foo(true); // `bool` does not implement `Index<u8>`
620 There will be an error about `bool` not implementing `Index<u8>`, followed by a
621 note saying "the type `bool` cannot be indexed by `u8`".
623 As you can see, you can specify type parameters in curly braces for
624 substitution with the actual types (using the regular format string syntax) in
625 a given situation. Furthermore, `{Self}` will substitute to the type (in this
626 case, `bool`) that we tried to use.
628 This error appears when the curly braces contain an identifier which doesn't
629 match with any of the type parameters or the string `Self`. This might happen
630 if you misspelled a type parameter, or if you intended to use literal curly
631 braces. If it is the latter, escape the curly braces with a second curly brace
632 of the same type; e.g., a literal `{` is `{{`.
636 The `#[rustc_on_unimplemented]` attribute lets you specify a custom error
637 message for when a particular trait isn't implemented on a type placed in a
638 position that needs that trait. For example, when the following code is
642 #![feature(on_unimplemented)]
644 fn foo<T: Index<u8>>(x: T){}
646 #[rustc_on_unimplemented = "the type `{Self}` cannot be indexed by `{Idx}`"]
647 trait Index<Idx> { /* ... */ }
649 foo(true); // `bool` does not implement `Index<u8>`
652 there will be an error about `bool` not implementing `Index<u8>`, followed by a
653 note saying "the type `bool` cannot be indexed by `u8`".
655 As you can see, you can specify type parameters in curly braces for
656 substitution with the actual types (using the regular format string syntax) in
657 a given situation. Furthermore, `{Self}` will substitute to the type (in this
658 case, `bool`) that we tried to use.
660 This error appears when the curly braces do not contain an identifier. Please
661 add one of the same name as a type parameter. If you intended to use literal
662 braces, use `{{` and `}}` to escape them.
666 The `#[rustc_on_unimplemented]` attribute lets you specify a custom error
667 message for when a particular trait isn't implemented on a type placed in a
668 position that needs that trait. For example, when the following code is
672 #![feature(on_unimplemented)]
674 fn foo<T: Index<u8>>(x: T){}
676 #[rustc_on_unimplemented = "the type `{Self}` cannot be indexed by `{Idx}`"]
677 trait Index<Idx> { /* ... */ }
679 foo(true); // `bool` does not implement `Index<u8>`
682 there will be an error about `bool` not implementing `Index<u8>`, followed by a
683 note saying "the type `bool` cannot be indexed by `u8`".
685 For this to work, some note must be specified. An empty attribute will not do
686 anything, please remove the attribute or add some helpful note for users of the
691 When using a lifetime like `'a` in a type, it must be declared before being
694 These two examples illustrate the problem:
696 ```compile_fail,E0261
697 // error, use of undeclared lifetime name `'a`
698 fn foo(x: &'a str) { }
701 // error, use of undeclared lifetime name `'a`
706 These can be fixed by declaring lifetime parameters:
713 fn foo<'a>(x: &'a str) {}
716 Impl blocks declare lifetime parameters separately. You need to add lifetime
717 parameters to an impl block if you're implementing a type that has a lifetime
718 parameter of its own.
721 ```compile_fail,E0261
726 // error, use of undeclared lifetime name `'a`
728 fn foo<'a>(x: &'a str) {}
732 This is fixed by declaring the impl block like this:
741 fn foo(x: &'a str) {}
747 Declaring certain lifetime names in parameters is disallowed. For example,
748 because the `'static` lifetime is a special built-in lifetime name denoting
749 the lifetime of the entire program, this is an error:
751 ```compile_fail,E0262
752 // error, invalid lifetime parameter name `'static`
753 fn foo<'static>(x: &'static str) { }
758 A lifetime name cannot be declared more than once in the same scope. For
761 ```compile_fail,E0263
762 // error, lifetime name `'a` declared twice in the same scope
763 fn foo<'a, 'b, 'a>(x: &'a str, y: &'b str) { }
768 An unknown external lang item was used. Erroneous code example:
770 ```compile_fail,E0264
771 #![feature(lang_items)]
774 #[lang = "cake"] // error: unknown external lang item: `cake`
779 A list of available external lang items is available in
780 `src/librustc/middle/weak_lang_items.rs`. Example:
783 #![feature(lang_items)]
786 #[lang = "panic_impl"] // ok!
793 This is because of a type mismatch between the associated type of some
794 trait (e.g., `T::Bar`, where `T` implements `trait Quux { type Bar; }`)
795 and another type `U` that is required to be equal to `T::Bar`, but is not.
798 Here is a basic example:
800 ```compile_fail,E0271
801 trait Trait { type AssociatedType; }
803 fn foo<T>(t: T) where T: Trait<AssociatedType=u32> {
807 impl Trait for i8 { type AssociatedType = &'static str; }
812 Here is that same example again, with some explanatory comments:
814 ```compile_fail,E0271
815 trait Trait { type AssociatedType; }
817 fn foo<T>(t: T) where T: Trait<AssociatedType=u32> {
818 // ~~~~~~~~ ~~~~~~~~~~~~~~~~~~
820 // This says `foo` can |
821 // only be used with |
823 // implements `Trait`. |
825 // This says not only must
826 // `T` be an impl of `Trait`
827 // but also that the impl
828 // must assign the type `u32`
829 // to the associated type.
833 impl Trait for i8 { type AssociatedType = &'static str; }
834 //~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
839 // ... but it is an implementation
840 // that assigns `&'static str` to
841 // the associated type.
844 // Here, we invoke `foo` with an `i8`, which does not satisfy
845 // the constraint `<i8 as Trait>::AssociatedType=u32`, and
846 // therefore the type-checker complains with this error code.
849 To avoid those issues, you have to make the types match correctly.
850 So we can fix the previous examples like this:
854 trait Trait { type AssociatedType; }
856 fn foo<T>(t: T) where T: Trait<AssociatedType = &'static str> {
860 impl Trait for i8 { type AssociatedType = &'static str; }
865 let vs = vec![1, 2, 3, 4];
877 This error occurs when there was a recursive trait requirement that overflowed
878 before it could be evaluated. Often this means that there is unbounded
879 recursion in resolving some type bounds.
881 For example, in the following code:
883 ```compile_fail,E0275
888 impl<T> Foo for T where Bar<T>: Foo {}
891 To determine if a `T` is `Foo`, we need to check if `Bar<T>` is `Foo`. However,
892 to do this check, we need to determine that `Bar<Bar<T>>` is `Foo`. To
893 determine this, we check if `Bar<Bar<Bar<T>>>` is `Foo`, and so on. This is
894 clearly a recursive requirement that can't be resolved directly.
896 Consider changing your trait bounds so that they're less self-referential.
900 This error occurs when a bound in an implementation of a trait does not match
901 the bounds specified in the original trait. For example:
903 ```compile_fail,E0276
909 fn foo<T>(x: T) where T: Copy {}
913 Here, all types implementing `Foo` must have a method `foo<T>(x: T)` which can
914 take any type `T`. However, in the `impl` for `bool`, we have added an extra
915 bound that `T` is `Copy`, which isn't compatible with the original trait.
917 Consider removing the bound from the method or adding the bound to the original
918 method definition in the trait.
922 You tried to use a type which doesn't implement some trait in a place which
923 expected that trait. Erroneous code example:
925 ```compile_fail,E0277
926 // here we declare the Foo trait with a bar method
931 // we now declare a function which takes an object implementing the Foo trait
932 fn some_func<T: Foo>(foo: T) {
937 // we now call the method with the i32 type, which doesn't implement
939 some_func(5i32); // error: the trait bound `i32 : Foo` is not satisfied
943 In order to fix this error, verify that the type you're using does implement
951 fn some_func<T: Foo>(foo: T) {
952 foo.bar(); // we can now use this method since i32 implements the
956 // we implement the trait on the i32 type
962 some_func(5i32); // ok!
966 Or in a generic context, an erroneous code example would look like:
968 ```compile_fail,E0277
969 fn some_func<T>(foo: T) {
970 println!("{:?}", foo); // error: the trait `core::fmt::Debug` is not
971 // implemented for the type `T`
975 // We now call the method with the i32 type,
976 // which *does* implement the Debug trait.
981 Note that the error here is in the definition of the generic function: Although
982 we only call it with a parameter that does implement `Debug`, the compiler
983 still rejects the function: It must work with all possible input types. In
984 order to make this example compile, we need to restrict the generic type we're
990 // Restrict the input type to types that implement Debug.
991 fn some_func<T: fmt::Debug>(foo: T) {
992 println!("{:?}", foo);
996 // Calling the method is still fine, as i32 implements Debug.
999 // This would fail to compile now:
1000 // struct WithoutDebug;
1001 // some_func(WithoutDebug);
1005 Rust only looks at the signature of the called function, as such it must
1006 already specify all requirements that will be used for every type parameter.
1010 #### Note: this error code is no longer emitted by the compiler.
1012 You tried to supply a type which doesn't implement some trait in a location
1013 which expected that trait. This error typically occurs when working with
1014 `Fn`-based types. Erroneous code example:
1017 fn foo<F: Fn(usize)>(x: F) { }
1020 // type mismatch: ... implements the trait `core::ops::Fn<(String,)>`,
1021 // but the trait `core::ops::Fn<(usize,)>` is required
1023 foo(|y: String| { });
1027 The issue in this case is that `foo` is defined as accepting a `Fn` with one
1028 argument of type `String`, but the closure we attempted to pass to it requires
1029 one arguments of type `usize`.
1033 This error indicates that type inference did not result in one unique possible
1034 type, and extra information is required. In most cases this can be provided
1035 by adding a type annotation. Sometimes you need to specify a generic type
1038 A common example is the `collect` method on `Iterator`. It has a generic type
1039 parameter with a `FromIterator` bound, which for a `char` iterator is
1040 implemented by `Vec` and `String` among others. Consider the following snippet
1041 that reverses the characters of a string:
1043 ```compile_fail,E0282
1044 let x = "hello".chars().rev().collect();
1047 In this case, the compiler cannot infer what the type of `x` should be:
1048 `Vec<char>` and `String` are both suitable candidates. To specify which type to
1049 use, you can use a type annotation on `x`:
1052 let x: Vec<char> = "hello".chars().rev().collect();
1055 It is not necessary to annotate the full type. Once the ambiguity is resolved,
1056 the compiler can infer the rest:
1059 let x: Vec<_> = "hello".chars().rev().collect();
1062 Another way to provide the compiler with enough information, is to specify the
1063 generic type parameter:
1066 let x = "hello".chars().rev().collect::<Vec<char>>();
1069 Again, you need not specify the full type if the compiler can infer it:
1072 let x = "hello".chars().rev().collect::<Vec<_>>();
1075 Apart from a method or function with a generic type parameter, this error can
1076 occur when a type parameter of a struct or trait cannot be inferred. In that
1077 case it is not always possible to use a type annotation, because all candidates
1078 have the same return type. For instance:
1080 ```compile_fail,E0282
1091 let number = Foo::bar();
1096 This will fail because the compiler does not know which instance of `Foo` to
1097 call `bar` on. Change `Foo::bar()` to `Foo::<T>::bar()` to resolve the error.
1101 This error occurs when the compiler doesn't have enough information
1102 to unambiguously choose an implementation.
1106 ```compile_fail,E0283
1113 impl Generator for Impl {
1114 fn create() -> u32 { 1 }
1119 impl Generator for AnotherImpl {
1120 fn create() -> u32 { 2 }
1124 let cont: u32 = Generator::create();
1125 // error, impossible to choose one of Generator trait implementation
1126 // Should it be Impl or AnotherImpl, maybe something else?
1130 To resolve this error use the concrete type:
1139 impl Generator for AnotherImpl {
1140 fn create() -> u32 { 2 }
1144 let gen1 = AnotherImpl::create();
1146 // if there are multiple methods with same name (different traits)
1147 let gen2 = <AnotherImpl as Generator>::create();
1153 This error occurs when the compiler is unable to unambiguously infer the
1154 return type of a function or method which is generic on return type, such
1155 as the `collect` method for `Iterator`s.
1159 ```compile_fail,E0284
1160 fn foo() -> Result<bool, ()> {
1161 let results = [Ok(true), Ok(false), Err(())].iter().cloned();
1162 let v: Vec<bool> = results.collect()?;
1163 // Do things with v...
1168 Here we have an iterator `results` over `Result<bool, ()>`.
1169 Hence, `results.collect()` can return any type implementing
1170 `FromIterator<Result<bool, ()>>`. On the other hand, the
1171 `?` operator can accept any type implementing `Try`.
1173 The author of this code probably wants `collect()` to return a
1174 `Result<Vec<bool>, ()>`, but the compiler can't be sure
1175 that there isn't another type `T` implementing both `Try` and
1176 `FromIterator<Result<bool, ()>>` in scope such that
1177 `T::Ok == Vec<bool>`. Hence, this code is ambiguous and an error
1180 To resolve this error, use a concrete type for the intermediate expression:
1183 fn foo() -> Result<bool, ()> {
1184 let results = [Ok(true), Ok(false), Err(())].iter().cloned();
1186 let temp: Result<Vec<bool>, ()> = results.collect();
1189 // Do things with v...
1194 Note that the type of `v` can now be inferred from the type of `temp`.
1198 This error occurs when the compiler was unable to infer the concrete type of a
1199 variable. It can occur for several cases, the most common of which is a
1200 mismatch in the expected type that the compiler inferred for a variable's
1201 initializing expression, and the actual type explicitly assigned to the
1206 ```compile_fail,E0308
1207 let x: i32 = "I am not a number!";
1208 // ~~~ ~~~~~~~~~~~~~~~~~~~~
1210 // | initializing expression;
1211 // | compiler infers type `&str`
1213 // type `i32` assigned to variable `x`
1218 The type definition contains some field whose type
1219 requires an outlives annotation. Outlives annotations
1220 (e.g., `T: 'a`) are used to guarantee that all the data in T is valid
1221 for at least the lifetime `'a`. This scenario most commonly
1222 arises when the type contains an associated type reference
1223 like `<T as SomeTrait<'a>>::Output`, as shown in this example:
1225 ```compile_fail,E0309
1226 // This won't compile because the applicable impl of
1227 // `SomeTrait` (below) requires that `T: 'a`, but the struct does
1228 // not have a matching where-clause.
1230 foo: <T as SomeTrait<'a>>::Output,
1233 trait SomeTrait<'a> {
1237 impl<'a, T> SomeTrait<'a> for T
1245 Here, the where clause `T: 'a` that appears on the impl is not known to be
1246 satisfied on the struct. To make this example compile, you have to add
1247 a where-clause like `T: 'a` to the struct definition:
1254 foo: <T as SomeTrait<'a>>::Output
1257 trait SomeTrait<'a> {
1261 impl<'a, T> SomeTrait<'a> for T
1271 Types in type definitions have lifetimes associated with them that represent
1272 how long the data stored within them is guaranteed to be live. This lifetime
1273 must be as long as the data needs to be alive, and missing the constraint that
1274 denotes this will cause this error.
1276 ```compile_fail,E0310
1277 // This won't compile because T is not constrained to the static lifetime
1278 // the reference needs
1284 This will compile, because it has the constraint on the type parameter:
1287 struct Foo<T: 'static> {
1294 Reference's lifetime of borrowed content doesn't match the expected lifetime.
1296 Erroneous code example:
1298 ```compile_fail,E0312
1299 pub fn opt_str<'a>(maybestr: &'a Option<String>) -> &'static str {
1300 if maybestr.is_none() {
1303 let s: &'a str = maybestr.as_ref().unwrap();
1304 s // Invalid lifetime!
1309 To fix this error, either lessen the expected lifetime or find a way to not have
1310 to use this reference outside of its current scope (by running the code directly
1311 in the same block for example?):
1314 // In this case, we can fix the issue by switching from "static" lifetime to 'a
1315 pub fn opt_str<'a>(maybestr: &'a Option<String>) -> &'a str {
1316 if maybestr.is_none() {
1319 let s: &'a str = maybestr.as_ref().unwrap();
1327 This error occurs when an `if` expression without an `else` block is used in a
1328 context where a type other than `()` is expected, for example a `let`
1331 ```compile_fail,E0317
1334 let a = if x == 5 { 1 };
1338 An `if` expression without an `else` block has the type `()`, so this is a type
1339 error. To resolve it, add an `else` block having the same type as the `if`
1344 This error indicates that some types or traits depend on each other
1345 and therefore cannot be constructed.
1347 The following example contains a circular dependency between two traits:
1349 ```compile_fail,E0391
1350 trait FirstTrait : SecondTrait {
1354 trait SecondTrait : FirstTrait {
1361 #### Note: this error code is no longer emitted by the compiler.
1363 In Rust 1.3, the default object lifetime bounds are expected to change, as
1364 described in [RFC 1156]. You are getting a warning because the compiler
1365 thinks it is possible that this change will cause a compilation error in your
1366 code. It is possible, though unlikely, that this is a false alarm.
1368 The heart of the change is that where `&'a Box<SomeTrait>` used to default to
1369 `&'a Box<SomeTrait+'a>`, it now defaults to `&'a Box<SomeTrait+'static>` (here,
1370 `SomeTrait` is the name of some trait type). Note that the only types which are
1371 affected are references to boxes, like `&Box<SomeTrait>` or
1372 `&[Box<SomeTrait>]`. More common types like `&SomeTrait` or `Box<SomeTrait>`
1375 To silence this warning, edit your code to use an explicit bound. Most of the
1376 time, this means that you will want to change the signature of a function that
1377 you are calling. For example, if the error is reported on a call like `foo(x)`,
1378 and `foo` is defined as follows:
1381 # trait SomeTrait {}
1382 fn foo(arg: &Box<SomeTrait>) { /* ... */ }
1385 You might change it to:
1388 # trait SomeTrait {}
1389 fn foo<'a>(arg: &'a Box<SomeTrait+'a>) { /* ... */ }
1392 This explicitly states that you expect the trait object `SomeTrait` to contain
1393 references (with a maximum lifetime of `'a`).
1395 [RFC 1156]: https://github.com/rust-lang/rfcs/blob/master/text/1156-adjust-default-object-bounds.md
1399 An invalid lint attribute has been given. Erroneous code example:
1401 ```compile_fail,E0452
1402 #![allow(foo = "")] // error: malformed lint attribute
1405 Lint attributes only accept a list of identifiers (where each identifier is a
1406 lint name). Ensure the attribute is of this form:
1409 #![allow(foo)] // ok!
1411 #![allow(foo, foo2)] // ok!
1416 A lint check attribute was overruled by a `forbid` directive set as an
1417 attribute on an enclosing scope, or on the command line with the `-F` option.
1419 Example of erroneous code:
1421 ```compile_fail,E0453
1422 #![forbid(non_snake_case)]
1424 #[allow(non_snake_case)]
1426 let MyNumber = 2; // error: allow(non_snake_case) overruled by outer
1427 // forbid(non_snake_case)
1431 The `forbid` lint setting, like `deny`, turns the corresponding compiler
1432 warning into a hard error. Unlike `deny`, `forbid` prevents itself from being
1433 overridden by inner attributes.
1435 If you're sure you want to override the lint check, you can change `forbid` to
1436 `deny` (or use `-D` instead of `-F` if the `forbid` setting was given as a
1437 command-line option) to allow the inner lint check attribute:
1440 #![deny(non_snake_case)]
1442 #[allow(non_snake_case)]
1444 let MyNumber = 2; // ok!
1448 Otherwise, edit the code to pass the lint check, and remove the overruled
1452 #![forbid(non_snake_case)]
1461 A lifetime bound was not satisfied.
1463 Erroneous code example:
1465 ```compile_fail,E0478
1466 // Check that the explicit lifetime bound (`'SnowWhite`, in this example) must
1467 // outlive all the superbounds from the trait (`'kiss`, in this example).
1469 trait Wedding<'t>: 't { }
1471 struct Prince<'kiss, 'SnowWhite> {
1472 child: Box<Wedding<'kiss> + 'SnowWhite>,
1473 // error: lifetime bound not satisfied
1477 In this example, the `'SnowWhite` lifetime is supposed to outlive the `'kiss`
1478 lifetime but the declaration of the `Prince` struct doesn't enforce it. To fix
1479 this issue, you need to specify it:
1482 trait Wedding<'t>: 't { }
1484 struct Prince<'kiss, 'SnowWhite: 'kiss> { // You say here that 'kiss must live
1485 // longer than 'SnowWhite.
1486 child: Box<Wedding<'kiss> + 'SnowWhite>, // And now it's all good!
1492 A reference has a longer lifetime than the data it references.
1494 Erroneous code example:
1496 ```compile_fail,E0491
1497 trait SomeTrait<'a> {
1501 impl<'a, T> SomeTrait<'a> for T {
1502 type Output = &'a T; // compile error E0491
1506 Here, the problem is that a reference type like `&'a T` is only valid
1507 if all the data in T outlives the lifetime `'a`. But this impl as written
1508 is applicable to any lifetime `'a` and any type `T` -- we have no guarantee
1509 that `T` outlives `'a`. To fix this, you can add a where clause like
1513 trait SomeTrait<'a> {
1517 impl<'a, T> SomeTrait<'a> for T
1521 type Output = &'a T; // compile error E0491
1527 A lifetime cannot be determined in the given situation.
1529 Erroneous code example:
1531 ```compile_fail,E0495
1532 fn transmute_lifetime<'a, 'b, T>(t: &'a (T,)) -> &'b T {
1533 match (&t,) { // error!
1538 let y = Box::new((42,));
1539 let x = transmute_lifetime(&y);
1542 In this code, you have two ways to solve this issue:
1543 1. Enforce that `'a` lives at least as long as `'b`.
1544 2. Use the same lifetime requirement for both input and output values.
1546 So for the first solution, you can do it by replacing `'a` with `'a: 'b`:
1549 fn transmute_lifetime<'a: 'b, 'b, T>(t: &'a (T,)) -> &'b T {
1550 match (&t,) { // ok!
1556 In the second you can do it by simply removing `'b` so they both use `'a`:
1559 fn transmute_lifetime<'a, T>(t: &'a (T,)) -> &'a T {
1560 match (&t,) { // ok!
1568 A lifetime name is shadowing another lifetime name.
1570 Erroneous code example:
1572 ```compile_fail,E0496
1578 fn f<'a>(x: &'a i32) { // error: lifetime name `'a` shadows a lifetime
1579 // name that is already in scope
1584 Please change the name of one of the lifetimes to remove this error. Example:
1592 fn f<'b>(x: &'b i32) { // ok!
1602 #### Note: this error code is no longer emitted by the compiler.
1604 A stability attribute was used outside of the standard library.
1606 Erroneous code example:
1609 #[stable] // error: stability attributes may not be used outside of the
1614 It is not possible to use stability attributes outside of the standard library.
1615 Also, for now, it is not possible to write deprecation messages either.
1619 This error indicates that a `#[repr(..)]` attribute was placed on an
1622 Examples of erroneous code:
1624 ```compile_fail,E0517
1632 struct Foo {bar: bool, baz: bool}
1640 * The `#[repr(C)]` attribute can only be placed on structs and enums.
1641 * The `#[repr(packed)]` and `#[repr(simd)]` attributes only work on structs.
1642 * The `#[repr(u8)]`, `#[repr(i16)]`, etc attributes only work on enums.
1644 These attributes do not work on typedefs, since typedefs are just aliases.
1646 Representations like `#[repr(u8)]`, `#[repr(i64)]` are for selecting the
1647 discriminant size for enums with no data fields on any of the variants, e.g.
1648 `enum Color {Red, Blue, Green}`, effectively setting the size of the enum to
1649 the size of the provided type. Such an enum can be cast to a value of the same
1650 type as well. In short, `#[repr(u8)]` makes the enum behave like an integer
1651 with a constrained set of allowed values.
1653 Only field-less enums can be cast to numerical primitives, so this attribute
1654 will not apply to structs.
1656 `#[repr(packed)]` reduces padding to make the struct size smaller. The
1657 representation of enums isn't strictly defined in Rust, and this attribute
1658 won't work on enums.
1660 `#[repr(simd)]` will give a struct consisting of a homogeneous series of machine
1661 types (i.e., `u8`, `i32`, etc) a representation that permits vectorization via
1662 SIMD. This doesn't make much sense for enums since they don't consist of a
1663 single list of data.
1667 This error indicates that an `#[inline(..)]` attribute was incorrectly placed
1668 on something other than a function or method.
1670 Examples of erroneous code:
1672 ```compile_fail,E0518
1682 `#[inline]` hints the compiler whether or not to attempt to inline a method or
1683 function. By default, the compiler does a pretty good job of figuring this out
1684 itself, but if you feel the need for annotations, `#[inline(always)]` and
1685 `#[inline(never)]` can override or force the compiler's decision.
1687 If you wish to apply this attribute to all methods in an impl, manually annotate
1688 each method; it is not possible to annotate the entire impl with an `#[inline]`
1693 The lang attribute is intended for marking special items that are built-in to
1694 Rust itself. This includes special traits (like `Copy` and `Sized`) that affect
1695 how the compiler behaves, as well as special functions that may be automatically
1696 invoked (such as the handler for out-of-bounds accesses when indexing a slice).
1697 Erroneous code example:
1699 ```compile_fail,E0522
1700 #![feature(lang_items)]
1703 fn cookie() -> ! { // error: definition of an unknown language item: `cookie`
1710 A closure was used but didn't implement the expected trait.
1712 Erroneous code example:
1714 ```compile_fail,E0525
1718 fn bar<T: Fn(u32)>(_: T) {}
1722 let closure = |_| foo(x); // error: expected a closure that implements
1723 // the `Fn` trait, but this closure only
1724 // implements `FnOnce`
1729 In the example above, `closure` is an `FnOnce` closure whereas the `bar`
1730 function expected an `Fn` closure. In this case, it's simple to fix the issue,
1731 you just have to implement `Copy` and `Clone` traits on `struct X` and it'll
1735 #[derive(Clone, Copy)] // We implement `Clone` and `Copy` traits.
1739 fn bar<T: Fn(u32)>(_: T) {}
1743 let closure = |_| foo(x);
1744 bar(closure); // ok!
1748 To understand better how closures work in Rust, read:
1749 https://doc.rust-lang.org/book/ch13-01-closures.html
1753 Conflicting representation hints have been used on a same item.
1755 Erroneous code example:
1758 #[repr(u32, u64)] // warning!
1762 In most cases (if not all), using just one representation hint is more than
1763 enough. If you want to have a representation hint depending on the current
1764 architecture, use `cfg_attr`. Example:
1767 #[cfg_attr(linux, repr(u32))]
1768 #[cfg_attr(not(linux), repr(u64))]
1774 The `main` function was incorrectly declared.
1776 Erroneous code example:
1778 ```compile_fail,E0580
1779 fn main(x: i32) { // error: main function has wrong type
1784 The `main` function prototype should never take arguments.
1793 If you want to get command-line arguments, use `std::env::args`. To exit with a
1794 specified exit code, use `std::process::exit`.
1798 Abstract return types (written `impl Trait` for some trait `Trait`) are only
1799 allowed as function and inherent impl return types.
1801 Erroneous code example:
1803 ```compile_fail,E0562
1805 let count_to_ten: impl Iterator<Item=usize> = 0..10;
1806 // error: `impl Trait` not allowed outside of function and inherent method
1808 for i in count_to_ten {
1814 Make sure `impl Trait` only appears in return-type position.
1817 fn count_to_n(n: usize) -> impl Iterator<Item=usize> {
1822 for i in count_to_n(10) { // ok!
1828 See [RFC 1522] for more details.
1830 [RFC 1522]: https://github.com/rust-lang/rfcs/blob/master/text/1522-conservative-impl-trait.md
1834 You tried to supply an `Fn`-based type with an incorrect number of arguments
1835 than what was expected.
1837 Erroneous code example:
1839 ```compile_fail,E0593
1840 fn foo<F: Fn()>(x: F) { }
1843 // [E0593] closure takes 1 argument but 0 arguments are required
1850 An unknown lint was used on the command line.
1855 rustc -D bogus omse_file.rs
1858 Maybe you just misspelled the lint name or the lint doesn't exist anymore.
1859 Either way, try to update/remove it in order to fix the error.
1863 This error code indicates a mismatch between the lifetimes appearing in the
1864 function signature (i.e., the parameter types and the return type) and the
1865 data-flow found in the function body.
1867 Erroneous code example:
1869 ```compile_fail,E0621
1870 fn foo<'a>(x: &'a i32, y: &i32) -> &'a i32 { // error: explicit lifetime
1871 // required in the type of
1873 if x > y { x } else { y }
1877 In the code above, the function is returning data borrowed from either `x` or
1878 `y`, but the `'a` annotation indicates that it is returning data only from `x`.
1879 To fix the error, the signature and the body must be made to match. Typically,
1880 this is done by updating the function signature. So, in this case, we change
1881 the type of `y` to `&'a i32`, like so:
1884 fn foo<'a>(x: &'a i32, y: &'a i32) -> &'a i32 {
1885 if x > y { x } else { y }
1889 Now the signature indicates that the function data borrowed from either `x` or
1890 `y`. Alternatively, you could change the body to not return data from `y`:
1893 fn foo<'a>(x: &'a i32, y: &i32) -> &'a i32 {
1900 The `#![feature]` attribute specified an unknown feature.
1902 Erroneous code example:
1904 ```compile_fail,E0635
1905 #![feature(nonexistent_rust_feature)] // error: unknown feature
1911 A `#![feature]` attribute was declared multiple times.
1913 Erroneous code example:
1915 ```compile_fail,E0636
1916 #![allow(stable_features)]
1918 #![feature(rust1)] // error: the feature `rust1` has already been declared
1924 A closure or generator was constructed that references its own type.
1928 ```compile-fail,E0644
1937 // Here, when `x` is called, the parameter `y` is equal to `x`.
1942 Rust does not permit a closure to directly reference its own type,
1943 either through an argument (as in the example above) or by capturing
1944 itself through its environment. This restriction helps keep closure
1945 inference tractable.
1947 The easiest fix is to rewrite your closure into a top-level function,
1948 or into a method. In some cases, you may also be able to have your
1949 closure call itself by capturing a `&Fn()` object or `fn()` pointer
1950 that refers to itself. That is permitting, since the closure would be
1951 invoking itself via a virtual call, and hence does not directly
1952 reference its own *type*.
1957 A `repr(transparent)` type was also annotated with other, incompatible
1958 representation hints.
1960 Erroneous code example:
1962 ```compile_fail,E0692
1963 #[repr(transparent, C)] // error: incompatible representation hints
1967 A type annotated as `repr(transparent)` delegates all representation concerns to
1968 another type, so adding more representation hints is contradictory. Remove
1969 either the `transparent` hint or the other hints, like this:
1972 #[repr(transparent)]
1976 Alternatively, move the other attributes to the contained type:
1985 #[repr(transparent)]
1986 struct FooWrapper(Foo);
1989 Note that introducing another `struct` just to have a place for the other
1990 attributes may have unintended side effects on the representation:
1993 #[repr(transparent)]
1999 #[repr(transparent)]
2000 struct Grams2(Float); // this is not equivalent to `Grams` above
2003 Here, `Grams2` is a not equivalent to `Grams` -- the former transparently wraps
2004 a (non-transparent) struct containing a single float, while `Grams` is a
2005 transparent wrapper around a float. This can make a difference for the ABI.
2009 A closure has been used as `static`.
2011 Erroneous code example:
2013 ```compile_fail,E0697
2015 static || {}; // used as `static`
2019 Closures cannot be used as `static`. They "save" the environment,
2020 and as such a static closure would save only a static environment
2021 which would consist only of variables with a static lifetime. Given
2022 this it would be better to use a proper function. The easiest fix
2023 is to remove the `static` keyword.
2027 When using generators (or async) all type variables must be bound so a
2028 generator can be constructed.
2030 Erroneous code example:
2032 ```edition2018,compile-fail,E0698
2033 async fn bar<T>() -> () {}
2036 bar().await; // error: cannot infer type for `T`
2040 In the above example `T` is unknowable by the compiler.
2041 To fix this you must bind `T` to a concrete type such as `String`
2042 so that a generator can then be constructed:
2045 async fn bar<T>() -> () {}
2048 bar::<String>().await;
2049 // ^^^^^^^^ specify type explicitly
2055 The `impl Trait` return type captures lifetime parameters that do not
2056 appear within the `impl Trait` itself.
2058 Erroneous code example:
2060 ```compile-fail,E0700
2061 use std::cell::Cell;
2065 impl<'a, 'b> Trait<'b> for Cell<&'a u32> { }
2067 fn foo<'x, 'y>(x: Cell<&'x u32>) -> impl Trait<'y>
2074 Here, the function `foo` returns a value of type `Cell<&'x u32>`,
2075 which references the lifetime `'x`. However, the return type is
2076 declared as `impl Trait<'y>` -- this indicates that `foo` returns
2077 "some type that implements `Trait<'y>`", but it also indicates that
2078 the return type **only captures data referencing the lifetime `'y`**.
2079 In this case, though, we are referencing data with lifetime `'x`, so
2080 this function is in error.
2082 To fix this, you must reference the lifetime `'x` from the return
2083 type. For example, changing the return type to `impl Trait<'y> + 'x`
2087 use std::cell::Cell;
2091 impl<'a,'b> Trait<'b> for Cell<&'a u32> { }
2093 fn foo<'x, 'y>(x: Cell<&'x u32>) -> impl Trait<'y> + 'x
2102 This error indicates that a `#[non_exhaustive]` attribute was incorrectly placed
2103 on something other than a struct or enum.
2105 Examples of erroneous code:
2107 ```compile_fail,E0701
2108 # #![feature(non_exhaustive)]
2116 This error indicates that a `#[lang = ".."]` attribute was placed
2117 on the wrong type of item.
2119 Examples of erroneous code:
2121 ```compile_fail,E0718
2122 #![feature(lang_items)]
2130 A stability attribute has been used outside of the standard library.
2132 Erroneous code examples:
2134 ```compile_fail,E0734
2135 #[rustc_deprecated(since = "b", reason = "text")] // invalid
2136 #[stable(feature = "a", since = "b")] // invalid
2137 #[unstable(feature = "b", issue = "0")] // invalid
2141 These attributes are meant to only be used by the standard library and are
2142 rejected in your own crates.
2146 #[track_caller] and #[naked] cannot be applied to the same function.
2148 Erroneous code example:
2150 ```compile_fail,E0736
2151 #![feature(track_caller)]
2158 This is primarily due to ABI incompatibilities between the two attributes.
2159 See [RFC 2091] for details on this and other limitations.
2161 [RFC 2091]: https://github.com/rust-lang/rfcs/blob/master/text/2091-inline-semantic.md
2165 // E0006, // merged with E0005
2166 // E0101, // replaced with E0282
2167 // E0102, // replaced with E0282
2170 // E0272, // on_unimplemented #0
2171 // E0273, // on_unimplemented #1
2172 // E0274, // on_unimplemented #2
2173 // E0278, // requirement is not satisfied
2174 E0279, // requirement is not satisfied
2175 E0280, // requirement is not satisfied
2176 // E0285, // overflow evaluation builtin bounds
2177 // E0296, // replaced with a generic attribute input check
2178 // E0300, // unexpanded macro
2179 // E0304, // expected signed integer constant
2180 // E0305, // expected constant
2181 E0311, // thing may not live long enough
2182 E0313, // lifetime of borrowed pointer outlives lifetime of captured
2184 E0314, // closure outlives stack frame
2185 E0315, // cannot invoke closure outside of its lifetime
2186 E0316, // nested quantification of lifetimes
2187 E0320, // recursive overflow during dropck
2188 E0473, // dereference of reference outside its lifetime
2189 E0474, // captured variable `..` does not outlive the enclosing closure
2190 E0475, // index of slice outside its lifetime
2191 E0476, // lifetime of the source pointer does not outlive lifetime bound...
2192 E0477, // the type `..` does not fulfill the required lifetime...
2193 E0479, // the type `..` (provided as the value of a type parameter) is...
2194 E0480, // lifetime of method receiver does not outlive the method call
2195 E0481, // lifetime of function argument does not outlive the function call
2196 E0482, // lifetime of return value does not outlive the function call
2197 E0483, // lifetime of operand does not outlive the operation
2198 E0484, // reference is not valid at the time of borrow
2199 E0485, // automatically reference is not valid at the time of borrow
2200 E0486, // type of expression contains references that are not valid during..
2201 E0487, // unsafe use of destructor: destructor might be called while...
2202 E0488, // lifetime of variable does not enclose its declaration
2203 E0489, // type/lifetime parameter not in scope here
2204 E0490, // a value of type `..` is borrowed for too long
2205 E0623, // lifetime mismatch where both parameters are anonymous regions
2206 E0628, // generators cannot have explicit parameters
2207 E0631, // type mismatch in closure arguments
2208 E0637, // "'_" is not a valid lifetime bound
2209 E0657, // `impl Trait` can only capture lifetimes bound at the fn level
2210 E0687, // in-band lifetimes cannot be used in `fn`/`Fn` syntax
2211 E0688, // in-band lifetimes cannot be mixed with explicit lifetime binders
2212 // E0707, // multiple elided lifetimes used in arguments of `async fn`
2213 E0708, // `async` non-`move` closures with parameters are not currently
2215 // E0709, // multiple different lifetimes used in arguments of `async fn`
2216 E0710, // an unknown tool name found in scoped lint
2217 E0711, // a feature has been declared with conflicting stability attributes
2218 // E0702, // replaced with a generic attribute input check
2219 E0726, // non-explicit (not `'_`) elided lifetime in unsupported position
2220 E0727, // `async` generators are not yet supported
2221 E0728, // `await` must be in an `async` function or block
2222 E0739, // invalid track_caller application/syntax