Rust Compiler Error Index

E0001 Note: this error code is no longer emitted by the compiler. This error suggests that the expression arm corresponding to the noted pattern will never be reached as for all possible values of the expression being matched, one of the preceding patterns will match. This means that perhaps some of the preceding patterns are too general, this one is too specific or the ordering is incorrect. For example, the following match block has too many arms: match Some ( 0 ) { Some ( bar ) = > { } x = > { } _ = > { } } Run match blocks have their patterns matched in order, so, for example, putting a wildcard arm above a more specific arm will make the latter arm irrelevant. Ensure the ordering of the match arm is correct and remove any superfluous arms.

E0002 Note: this error code is no longer emitted by the compiler. This error indicates that an empty match expression is invalid because the type it is matching on is non-empty (there exist values of this type). In safe code it is impossible to create an instance of an empty type, so empty match expressions are almost never desired. This error is typically fixed by adding one or more cases to the match expression. An example of an empty type is enum Empty { } . So, the following will work: enum Empty {} fn foo ( x : Empty ) { match x { } } Run However, this won't: ⓘ This example deliberately fails to compile fn foo ( x : Option < String > ) { match x { } } Run

E0004 This error indicates that the compiler cannot guarantee a matching pattern for one or more possible inputs to a match expression. Guaranteed matches are required in order to assign values to match expressions, or alternatively, determine the flow of execution. Erroneous code example: ⓘ This example deliberately fails to compile enum Terminator { HastaLaVistaBaby , TalkToMyHand , } let x = Terminator :: HastaLaVistaBaby ; match x { Terminator :: TalkToMyHand = > {} } Run If you encounter this error you must alter your patterns so that every possible value of the input type is matched. For types with a small number of variants (like enums) you should probably cover all cases explicitly. Alternatively, the underscore _ wildcard pattern can be added after all other patterns to match "anything else". Example: enum Terminator { HastaLaVistaBaby , TalkToMyHand , } let x = Terminator :: HastaLaVistaBaby ; match x { Terminator :: TalkToMyHand = > {} Terminator :: HastaLaVistaBaby = > {} } match x { Terminator :: TalkToMyHand = > {} _ = > {} } Run

E0005 Patterns used to bind names must be irrefutable, that is, they must guarantee that a name will be extracted in all cases. Erroneous code example: ⓘ This example deliberately fails to compile let x = Some ( 1 ); let Some ( y ) = x ; Run If you encounter this error you probably need to use a match or if let to deal with the possibility of failure. Example: let x = Some ( 1 ); match x { Some ( y ) = > { }, None = > {} } if let Some ( y ) = x { } Run

E0007 This error indicates that the bindings in a match arm would require a value to be moved into more than one location, thus violating unique ownership. Code like the following is invalid as it requires the entire Option<String> to be moved into a variable called op_string while simultaneously requiring the inner String to be moved into a variable called s . Erroneous code example: ⓘ This example deliberately fails to compile let x = Some ( "s" . to_string ()); match x { op_string @ Some ( s ) = > {}, None = > {}, } Run See also the error E0303.

E0009 Note: this error code is no longer emitted by the compiler. In a pattern, all values that don't implement the Copy trait have to be bound the same way. The goal here is to avoid binding simultaneously by-move and by-ref. This limitation may be removed in a future version of Rust. Erroneous code example: #![ feature ( move_ref_pattern )] struct X { x : (), } let x = Some (( X { x : () }, X { x : () })); match x { Some (( y , ref z )) = > {}, None = > panic ! () } Run You have two solutions: Solution #1: Bind the pattern's values the same way. struct X { x : (), } let x = Some (( X { x : () }, X { x : () })); match x { Some (( ref y , ref z )) = > {}, None = > panic ! () } Run Solution #2: Implement the Copy trait for the X structure. However, please keep in mind that the first solution should be preferred. #[ derive ( Clone , Copy )] struct X { x : (), } let x = Some (( X { x : () }, X { x : () })); match x { Some (( y , ref z )) = > {}, None = > panic ! () } Run

E0010 The value of statics and constants must be known at compile time, and they live for the entire lifetime of a program. Creating a boxed value allocates memory on the heap at runtime, and therefore cannot be done at compile time. Erroneous code example: ⓘ This example deliberately fails to compile #![ feature ( box_syntax )] const CON : Box < i32 > = box 0 ; Run

E0013 Static and const variables can refer to other const variables. But a const variable cannot refer to a static variable. Erroneous code example: ⓘ This example deliberately fails to compile static X : i32 = 42 ; const Y : i32 = X ; Run In this example, Y cannot refer to X here. To fix this, the value can be extracted as a const and then used: const A : i32 = 42 ; static X : i32 = A ; const Y : i32 = A ; Run

E0014 Note: this error code is no longer emitted by the compiler. Constants can only be initialized by a constant value or, in a future version of Rust, a call to a const function. This error indicates the use of a path (like a::b, or x) denoting something other than one of these allowed items. Erroneous code example: const FOO : i32 = { let x = 0 ; x }; Run To avoid it, you have to replace the non-constant value: const FOO : i32 = { const X : i32 = 0 ; X }; const FOO2 : i32 = { 0 }; Run

E0015 A constant item was initialized with something that is not a constant expression. Erroneous code example: ⓘ This example deliberately fails to compile fn create_some () - > Option < u8 > { Some ( 1 ) } const FOO : Option < u8 > = create_some (); Run The only functions that can be called in static or constant expressions are const functions, and struct/enum constructors. To fix this error, you can declare create_some as a constant function: const fn create_some () - > Option < u8 > { Some ( 1 ) } const FOO : Option < u8 > = create_some (); struct Bar { x : u8 , } const OTHER_FOO : Option < u8 > = Some ( 1 ); const BAR : Bar = Bar { x : 1 }; Run

E0019 A function call isn't allowed in the const's initialization expression because the expression's value must be known at compile-time. Erroneous code example: ⓘ This example deliberately fails to compile #![ feature ( box_syntax )] fn main () { struct MyOwned ; static STATIC11 : Box < MyOwned > = box MyOwned ; } Run Remember: you can't use a function call inside a const's initialization expression! However, you can totally use it anywhere else: enum Test { V1 } impl Test { fn func ( & self ) - > i32 { 12 } } fn main () { const FOO : Test = Test :: V1 ; FOO . func (); let x = FOO . func (); } Run

E0023 A pattern attempted to extract an incorrect number of fields from a variant. Erroneous code example: ⓘ This example deliberately fails to compile enum Fruit { Apple ( String , String ), Pear ( u32 ), } let x = Fruit :: Apple ( String :: new (), String :: new ()); match x { Fruit :: Apple ( a ) = > {}, _ = > {} } Run A pattern used to match against an enum variant must provide a sub-pattern for each field of the enum variant. Here the Apple variant has two fields, and should be matched against like so: enum Fruit { Apple ( String , String ), Pear ( u32 ), } let x = Fruit :: Apple ( String :: new (), String :: new ()); match x { Fruit :: Apple ( a , b ) = > {}, _ = > {} } Run Matching with the wrong number of fields has no sensible interpretation: ⓘ This example deliberately fails to compile enum Fruit { Apple ( String , String ), Pear ( u32 ), } let x = Fruit :: Apple ( String :: new (), String :: new ()); match x { Fruit :: Apple ( a ) = > {}, Fruit :: Apple ( a , b , c ) = > {}, } Run Check how many fields the enum was declared with and ensure that your pattern uses the same number.

E0025 Each field of a struct can only be bound once in a pattern. Erroneous code example: ⓘ This example deliberately fails to compile struct Foo { a : u8 , b : u8 , } fn main (){ let x = Foo { a : 1 , b : 2 }; let Foo { a : x , a : y } = x ; } Run Each occurrence of a field name binds the value of that field, so to fix this error you will have to remove or alter the duplicate uses of the field name. Perhaps you misspelled another field name? Example: struct Foo { a : u8 , b : u8 , } fn main (){ let x = Foo { a : 1 , b : 2 }; let Foo { a : x , b : y } = x ; } Run

E0026 A struct pattern attempted to extract a non-existent field from a struct. Erroneous code example: ⓘ This example deliberately fails to compile struct Thing { x : u32 , y : u32 , } let thing = Thing { x : 0 , y : 0 }; match thing { Thing { x , z } = > {} } Run If you are using shorthand field patterns but want to refer to the struct field by a different name, you should rename it explicitly. Struct fields are identified by the name used before the colon : so struct patterns should resemble the declaration of the struct type being matched. struct Thing { x : u32 , y : u32 , } let thing = Thing { x : 0 , y : 0 }; match thing { Thing { x , y : z } = > {} } Run

E0027 A pattern for a struct fails to specify a sub-pattern for every one of the struct's fields. Erroneous code example: ⓘ This example deliberately fails to compile struct Dog { name : String , age : u32 , } let d = Dog { name : "Rusty" . to_string (), age : 8 }; match d { Dog { age : x } = > {} } Run To fix this error, ensure that each field from the struct's definition is mentioned in the pattern, or use .. to ignore unwanted fields. Example: struct Dog { name : String , age : u32 , } let d = Dog { name : "Rusty" . to_string (), age : 8 }; match d { Dog { name : ref n , age : x } = > {} } match d { Dog { age : x , .. } = > {} } Run

E0029 Something other than numbers and characters has been used for a range. Erroneous code example: ⓘ This example deliberately fails to compile let string = "salutations !" ; match string { "hello" .. = "world" = > {} _ = > {} } match string { s if s > = "hello" & & s < = "world" = > {} _ = > {} } Run In a match expression, only numbers and characters can be matched against a range. This is because the compiler checks that the range is non-empty at compile-time, and is unable to evaluate arbitrary comparison functions. If you want to capture values of an orderable type between two end-points, you can use a guard.

E0030 When matching against a range, the compiler verifies that the range is non-empty. Range patterns include both end-points, so this is equivalent to requiring the start of the range to be less than or equal to the end of the range. Erroneous code example: ⓘ This example deliberately fails to compile match 5u32 { 1 .. = 1 = > {} 1000 .. = 5 = > {} } Run

E0033 A trait type has been dereferenced. Erroneous code example: ⓘ This example deliberately fails to compile let trait_obj : & SomeTrait = & "some_value" ; let & invalid = trait_obj ; trait_obj . method_one (); trait_obj . method_two (); Run A pointer to a trait type cannot be implicitly dereferenced by a pattern. Every trait defines a type, but because the size of trait implementers isn't fixed, this type has no compile-time size. Therefore, all accesses to trait types must be through pointers. If you encounter this error you should try to avoid dereferencing the pointer. You can read more about trait objects in the Trait Objects section of the Reference.

E0034 The compiler doesn't know what method to call because more than one method has the same prototype. Erroneous code example: ⓘ This example deliberately fails to compile struct Test ; trait Trait1 { fn foo (); } trait Trait2 { fn foo (); } impl Trait1 for Test { fn foo () {} } impl Trait2 for Test { fn foo () {} } fn main () { Test :: foo () } Run To avoid this error, you have to keep only one of them and remove the others. So let's take our example and fix it: struct Test ; trait Trait1 { fn foo (); } impl Trait1 for Test { fn foo () {} } fn main () { Test :: foo () } Run However, a better solution would be using fully explicit naming of type and trait: struct Test ; trait Trait1 { fn foo (); } trait Trait2 { fn foo (); } impl Trait1 for Test { fn foo () {} } impl Trait2 for Test { fn foo () {} } fn main () { < Test as Trait1 > :: foo () } Run One last example: trait F { fn m ( & self ); } trait G { fn m ( & self ); } struct X ; impl F for X { fn m ( & self ) { println ! ( "I am F" ); } } impl G for X { fn m ( & self ) { println ! ( "I am G" ); } } fn main () { let f = X ; F :: m ( & f ); G :: m ( & f ); } Run

E0038 Trait objects like Box<Trait> can only be constructed when certain requirements are satisfied by the trait in question. Trait objects are a form of dynamic dispatch and use a dynamically sized type for the inner type. So, for a given trait Trait , when Trait is treated as a type, as in Box<Trait> , the inner type is 'unsized'. In such cases the boxed pointer is a 'fat pointer' that contains an extra pointer to a table of methods (among other things) for dynamic dispatch. This design mandates some restrictions on the types of traits that are allowed to be used in trait objects, which are collectively termed as 'object safety' rules. Attempting to create a trait object for a non object-safe trait will trigger this error. There are various rules: The trait cannot require Self: Sized When Trait is treated as a type, the type does not implement the special Sized trait, because the type does not have a known size at compile time and can only be accessed behind a pointer. Thus, if we have a trait like the following: trait Foo where Self : Sized { } Run We cannot create an object of type Box<Foo> or &Foo since in this case Self would not be Sized . Generally, Self: Sized is used to indicate that the trait should not be used as a trait object. If the trait comes from your own crate, consider removing this restriction. Method references the Self type in its parameters or return type This happens when a trait has a method like the following: trait Trait { fn foo ( & self ) - > Self ; } impl Trait for String { fn foo ( & self ) - > Self { "hi" . to_owned () } } impl Trait for u8 { fn foo ( & self ) - > Self { 1 } } Run (Note that &self and &mut self are okay, it's additional Self types which cause this problem.) In such a case, the compiler cannot predict the return type of foo() in a situation like the following: ⓘ This example deliberately fails to compile trait Trait { fn foo ( & self ) - > Self ; } fn call_foo ( x : Box < Trait > ) { let y = x . foo (); } Run If only some methods aren't object-safe, you can add a where Self: Sized bound on them to mark them as explicitly unavailable to trait objects. The functionality will still be available to all other implementers, including Box<Trait> which is itself sized (assuming you impl Trait for Box<Trait> ). trait Trait { fn foo ( & self ) - > Self where Self : Sized ; } Run Now, foo() can no longer be called on a trait object, but you will now be allowed to make a trait object, and that will be able to call any object-safe methods. With such a bound, one can still call foo() on types implementing that trait that aren't behind trait objects. Method has generic type parameters As mentioned before, trait objects contain pointers to method tables. So, if we have: trait Trait { fn foo ( & self ); } impl Trait for String { fn foo ( & self ) { } } impl Trait for u8 { fn foo ( & self ) { } } Run At compile time each implementation of Trait will produce a table containing the various methods (and other items) related to the implementation. This works fine, but when the method gains generic parameters, we can have a problem. Usually, generic parameters get monomorphized. For example, if I have fn foo < T > ( x : T ) { } Run The machine code for foo::<u8>() , foo::<bool>() , foo::<String>() , or any other type substitution is different. Hence the compiler generates the implementation on-demand. If you call foo() with a bool parameter, the compiler will only generate code for foo::<bool>() . When we have additional type parameters, the number of monomorphized implementations the compiler generates does not grow drastically, since the compiler will only generate an implementation if the function is called with unparametrized substitutions (i.e., substitutions where none of the substituted types are themselves parameterized). However, with trait objects we have to make a table containing every object that implements the trait. Now, if it has type parameters, we need to add implementations for every type that implements the trait, and there could theoretically be an infinite number of types. For example, with: trait Trait { fn foo < T > ( & self , on : T ); } impl Trait for String { fn foo < T > ( & self , on : T ) { } } impl Trait for u8 { fn foo < T > ( & self , on : T ) { } } Run Now, if we have the following code: ⓘ This example deliberately fails to compile fn call_foo ( thing : Box < Trait > ) { thing . foo ( true ); thing . foo ( 1 ); thing . foo ( "hello" ); } Run We don't just need to create a table of all implementations of all methods of Trait , we need to create such a table, for each different type fed to foo() . In this case this turns out to be (10 types implementing Trait )*(3 types being fed to foo() ) = 30 implementations! With real world traits these numbers can grow drastically. To fix this, it is suggested to use a where Self: Sized bound similar to the fix for the sub-error above if you do not intend to call the method with type parameters: trait Trait { fn foo < T > ( & self , on : T ) where Self : Sized ; } Run If this is not an option, consider replacing the type parameter with another trait object (e.g., if T: OtherTrait , use on: Box<OtherTrait> ). If the number of types you intend to feed to this method is limited, consider manually listing out the methods of different types. Method has no receiver Methods that do not take a self parameter can't be called since there won't be a way to get a pointer to the method table for them. trait Foo { fn foo () - > u8 ; } Run This could be called as <Foo as Foo>::foo() , which would not be able to pick an implementation. Adding a Self: Sized bound to these methods will generally make this compile. trait Foo { fn foo () - > u8 where Self : Sized ; } Run The trait cannot contain associated constants Just like static functions, associated constants aren't stored on the method table. If the trait or any subtrait contain an associated constant, they cannot be made into an object. ⓘ This example deliberately fails to compile trait Foo { const X : i32 ; } impl Foo {} Run A simple workaround is to use a helper method instead: trait Foo { fn x ( & self ) - > i32 ; } Run The trait cannot use Self as a type parameter in the supertrait listing This is similar to the second sub-error, but subtler. It happens in situations like the following: ⓘ This example deliberately fails to compile trait Super < A : ? Sized > {} trait Trait : Super < Self > { } struct Foo ; impl Super < Foo > for Foo {} impl Trait for Foo {} fn main () { let x : Box < dyn Trait > ; } Run Here, the supertrait might have methods as follows: trait Super < A : ? Sized > { fn get_a ( & self ) - > & A ; } Run If the trait Trait was deriving from something like Super<String> or Super<T> (where Foo itself is Foo<T> ), this is okay, because given a type get_a() will definitely return an object of that type. However, if it derives from Super<Self> , even though Super is object safe, the method get_a() would return an object of unknown type when called on the function. Self type parameters let us make object safe traits no longer safe, so they are forbidden when specifying supertraits. There's no easy fix for this, generally code will need to be refactored so that you no longer need to derive from Super<Self> .

E0040 It is not allowed to manually call destructors in Rust. Erroneous code example: ⓘ This example deliberately fails to compile struct Foo { x : i32 , } impl Drop for Foo { fn drop ( & mut self ) { println ! ( "kaboom" ); } } fn main () { let mut x = Foo { x : - 7 }; x . drop (); } Run It is unnecessary to do this since drop is called automatically whenever a value goes out of scope. However, if you really need to drop a value by hand, you can use the std::mem::drop function: struct Foo { x : i32 , } impl Drop for Foo { fn drop ( & mut self ) { println ! ( "kaboom" ); } } fn main () { let mut x = Foo { x : - 7 }; drop ( x ); } Run

E0044 You cannot use type or const parameters on foreign items. Example of erroneous code: ⓘ This example deliberately fails to compile extern { fn some_func < T > ( x : T ); } Run To fix this, replace the generic parameter with the specializations that you need: extern { fn some_func_i32 ( x : i32 ); } extern { fn some_func_i64 ( x : i64 ); } Run

E0045 Variadic parameters have been used on a non-C ABI function. Erroneous code example: ⓘ This example deliberately fails to compile #![ feature ( unboxed_closures )] extern "rust-call" { fn foo ( x : u8 , ...); } Run Rust only supports variadic parameters for interoperability with C code in its FFI. As such, variadic parameters can only be used with functions which are using the C ABI. To fix such code, put them in an extern "C" block: extern "C" { fn foo ( x : u8 , ...); } Run

E0046 Items are missing in a trait implementation. Erroneous code example: ⓘ This example deliberately fails to compile trait Foo { fn foo (); } struct Bar ; impl Foo for Bar {} Run When trying to make some type implement a trait Foo , you must, at minimum, provide implementations for all of Foo 's required methods (meaning the methods that do not have default implementations), as well as any required trait items like associated types or constants. Example: trait Foo { fn foo (); } struct Bar ; impl Foo for Bar { fn foo () {} } Run

E0049 An attempted implementation of a trait method has the wrong number of type or const parameters. Erroneous code example: ⓘ This example deliberately fails to compile trait Foo { fn foo < T : Default > ( x : T ) - > Self ; } struct Bar ; impl Foo for Bar { fn foo ( x : bool ) - > Self { Bar } } Run For example, the Foo trait has a method foo with a type parameter T , but the implementation of foo for the type Bar is missing this parameter. To fix this error, they must have the same type parameters: trait Foo { fn foo < T : Default > ( x : T ) - > Self ; } struct Bar ; impl Foo for Bar { fn foo < T : Default > ( x : T ) - > Self { Bar } } Run

E0050 An attempted implementation of a trait method has the wrong number of function parameters. Erroneous code example: ⓘ This example deliberately fails to compile trait Foo { fn foo ( & self , x : u8 ) - > bool ; } struct Bar ; impl Foo for Bar { fn foo ( & self ) - > bool { true } } Run For example, the Foo trait has a method foo with two function parameters ( &self and u8 ), but the implementation of foo for the type Bar omits the u8 parameter. To fix this error, they must have the same parameters: trait Foo { fn foo ( & self , x : u8 ) - > bool ; } struct Bar ; impl Foo for Bar { fn foo ( & self , x : u8 ) - > bool { true } } Run

E0053 The parameters of any trait method must match between a trait implementation and the trait definition. Erroneous code example: ⓘ This example deliberately fails to compile trait Foo { fn foo ( x : u16 ); fn bar ( & self ); } struct Bar ; impl Foo for Bar { fn foo ( x : i16 ) { } fn bar ( & mut self ) { } } Run

E0054 It is not allowed to cast to a bool. Erroneous code example: ⓘ This example deliberately fails to compile let x = 5 ; let x_is_nonzero = x as bool ; Run If you are trying to cast a numeric type to a bool, you can compare it with zero instead: let x = 5 ; let x_is_nonzero = x ! = 0 ; Run

E0055 During a method call, a value is automatically dereferenced as many times as needed to make the value's type match the method's receiver. The catch is that the compiler will only attempt to dereference a number of times up to the recursion limit (which can be set via the recursion_limit attribute). For a somewhat artificial example: ⓘ This example deliberately fails to compile #![ recursion_limit = "4" ] struct Foo ; impl Foo { fn foo ( & self ) {} } fn main () { let foo = Foo ; let ref_foo = & & & & & Foo ; ref_foo . foo (); } Run One fix may be to increase the recursion limit. Note that it is possible to create an infinite recursion of dereferencing, in which case the only fix is to somehow break the recursion.

E0057 An invalid number of arguments was given when calling a closure. Erroneous code example: ⓘ This example deliberately fails to compile let f = | x | x * 3 ; let a = f (); let b = f ( 4 ); let c = f ( 2 , 3 ); Run When invoking closures or other implementations of the function traits Fn , FnMut or FnOnce using call notation, the number of parameters passed to the function must match its definition. A generic function must be treated similarly: fn foo < F : Fn () > ( f : F ) { f (); } Run

E0059 The built-in function traits are generic over a tuple of the function arguments. If one uses angle-bracket notation ( Fn<(T,), Output=U> ) instead of parentheses ( Fn(T) -> U ) to denote the function trait, the type parameter should be a tuple. Otherwise function call notation cannot be used and the trait will not be implemented by closures. The most likely source of this error is using angle-bracket notation without wrapping the function argument type into a tuple, for example: ⓘ This example deliberately fails to compile #![ feature ( unboxed_closures )] fn foo < F : Fn < i32 > > ( f : F ) - > F :: Output { f ( 3 ) } Run It can be fixed by adjusting the trait bound like this: #![ feature ( unboxed_closures )] fn foo < F : Fn < ( i32 ,) > > ( f : F ) - > F :: Output { f ( 3 ) } Run Note that (T,) always denotes the type of a 1-tuple containing an element of type T . The comma is necessary for syntactic disambiguation.

E0060 External C functions are allowed to be variadic. However, a variadic function takes a minimum number of arguments. For example, consider C's variadic printf function: ⓘ This example deliberately fails to compile use std :: os :: raw ::{ c_char , c_int }; extern "C" { fn printf ( _ : * const c_char , ...) - > c_int ; } unsafe { printf (); } Run Using this declaration, it must be called with at least one argument, so simply calling printf() is invalid. But the following uses are allowed: unsafe { use std :: ffi :: CString ; let fmt = CString :: new ( "test

" ). unwrap (); printf ( fmt . as_ptr ()); let fmt = CString :: new ( "number = %d

" ). unwrap (); printf ( fmt . as_ptr (), 3 ); let fmt = CString :: new ( "%d, %d

" ). unwrap (); printf ( fmt . as_ptr (), 10 , 5 ); } Run

E0061 An invalid number of arguments was passed when calling a function. Erroneous code example: ⓘ This example deliberately fails to compile fn f ( u : i32 ) {} f (); Run The number of arguments passed to a function must match the number of arguments specified in the function signature. For example, a function like: fn f ( a : u16 , b : & str ) {} Run Must always be called with exactly two arguments, e.g., f(2, "test") . Note that Rust does not have a notion of optional function arguments or variadic functions (except for its C-FFI).

E0062 A struct's or struct-like enum variant's field was specified more than once. Erroneous code example: ⓘ This example deliberately fails to compile struct Foo { x : i32 , } fn main () { let x = Foo { x : 0 , x : 0 , }; } Run This error indicates that during an attempt to build a struct or struct-like enum variant, one of the fields was specified more than once. Each field should be specified exactly one time. Example: struct Foo { x : i32 , } fn main () { let x = Foo { x : 0 }; } Run

E0063 A struct's or struct-like enum variant's field was not provided. Erroneous code example: ⓘ This example deliberately fails to compile struct Foo { x : i32 , y : i32 , } fn main () { let x = Foo { x : 0 }; } Run Each field should be specified exactly once. Example: struct Foo { x : i32 , y : i32 , } fn main () { let x = Foo { x : 0 , y : 0 }; } Run

E0067 An invalid left-hand side expression was used on an assignment operation. Erroneous code example: ⓘ This example deliberately fails to compile 12 + = 1 ; Run You need to have a place expression to be able to assign it something. For example: let mut x : i8 = 12 ; x + = 1 ; Run

E0069 The compiler found a function whose body contains a return; statement but whose return type is not () . Erroneous code example: ⓘ This example deliberately fails to compile fn foo () - > u8 { return ; } Run Since return; is just like return (); , there is a mismatch between the function's return type and the value being returned.

E0070 An assignment operator was used on a non-place expression. Erroneous code examples: ⓘ This example deliberately fails to compile struct SomeStruct { x : i32 , y : i32 , } const SOME_CONST : i32 = 12 ; fn some_other_func () {} fn some_function () { SOME_CONST = 14 ; 1 = 3 ; some_other_func () = 4 ; SomeStruct :: x = 12 ; } Run The left-hand side of an assignment operator must be a place expression. A place expression represents a memory location and can be a variable (with optional namespacing), a dereference, an indexing expression or a field reference. More details can be found in the Expressions section of the Reference. And now let's give working examples: struct SomeStruct { x : i32 , y : i32 , } let mut s = SomeStruct { x : 0 , y : 0 }; s . x = 3 ; fn some_func ( x : & mut i32 ) { * x = 12 ; } Run

E0071 A structure-literal syntax was used to create an item that is not a structure or enum variant. Example of erroneous code: ⓘ This example deliberately fails to compile type U32 = u32 ; let t = U32 { value : 4 }; Run To fix this, ensure that the name was correctly spelled, and that the correct form of initializer was used. For example, the code above can be fixed to: enum Foo { FirstValue ( i32 ) } fn main () { let u = Foo :: FirstValue ( 0i32 ); let t = 4 ; } Run

E0072 A recursive type has infinite size because it doesn't have an indirection. Erroneous code example: ⓘ This example deliberately fails to compile struct ListNode { head : u8 , tail : Option < ListNode > , } Run When defining a recursive struct or enum, any use of the type being defined from inside the definition must occur behind a pointer (like Box , & or Rc ). This is because structs and enums must have a well-defined size, and without the pointer, the size of the type would need to be unbounded. In the example, the type cannot have a well-defined size, because it needs to be arbitrarily large (since we would be able to nest ListNode s to any depth). Specifically, size of `ListNode` = 1 byte for `head` + 1 byte for the discriminant of the `Option` + size of `ListNode` One way to fix this is by wrapping ListNode in a Box , like so: struct ListNode { head : u8 , tail : Option < Box < ListNode > > , } Run This works because Box is a pointer, so its size is well-known.

E0073 Note: this error code is no longer emitted by the compiler. You cannot define a struct (or enum) Foo that requires an instance of Foo in order to make a new Foo value. This is because there would be no way a first instance of Foo could be made to initialize another instance! Here's an example of a struct that has this problem: struct Foo { x : Box < Foo > } Run One fix is to use Option , like so: struct Foo { x : Option < Box < Foo > > } Run Now it's possible to create at least one instance of Foo : Foo { x: None } .

E0074 Note: this error code is no longer emitted by the compiler. When using the #[simd] attribute on a tuple struct, the components of the tuple struct must all be of a concrete, nongeneric type so the compiler can reason about how to use SIMD with them. This error will occur if the types are generic. This will cause an error: #![ feature ( repr_simd )] #[ repr ( simd )] struct Bad < T > ( T , T , T ); Run This will not: #![ feature ( repr_simd )] #[ repr ( simd )] struct Good ( u32 , u32 , u32 ); Run

E0075 A #[simd] attribute was applied to an empty tuple struct. Erroneous code example: ⓘ This example deliberately fails to compile #![ feature ( repr_simd )] #[ repr ( simd )] struct Bad ; Run The #[simd] attribute can only be applied to non empty tuple structs, because it doesn't make sense to try to use SIMD operations when there are no values to operate on. Fixed example: #![ feature ( repr_simd )] #[ repr ( simd )] struct Good ( u32 ); Run

E0076 All types in a tuple struct aren't the same when using the #[simd] attribute. Erroneous code example: ⓘ This example deliberately fails to compile #![ feature ( repr_simd )] #[ repr ( simd )] struct Bad ( u16 , u32 , u32 ); Run When using the #[simd] attribute to automatically use SIMD operations in tuple struct, the types in the struct must all be of the same type, or the compiler will trigger this error. Fixed example: #![ feature ( repr_simd )] #[ repr ( simd )] struct Good ( u32 , u32 , u32 ); Run

E0077 A tuple struct's element isn't a machine type when using the #[simd] attribute. Erroneous code example: ⓘ This example deliberately fails to compile #![ feature ( repr_simd )] #[ repr ( simd )] struct Bad ( String ); Run When using the #[simd] attribute on a tuple struct, the elements in the tuple must be machine types so SIMD operations can be applied to them. Fixed example: #![ feature ( repr_simd )] #[ repr ( simd )] struct Good ( u32 , u32 , u32 ); Run

E0080 A constant value failed to get evaluated. Erroneous code example: ⓘ This example deliberately fails to compile enum Enum { X = ( 1 < < 500 ), Y = ( 1 / 0 ), } Run This error indicates that the compiler was unable to sensibly evaluate a constant expression that had to be evaluated. Attempting to divide by 0 or causing an integer overflow are two ways to induce this error. Ensure that the expressions given can be evaluated as the desired integer type. See the Custom Discriminants section of the Reference for more information about setting custom integer types on fieldless enums using the repr attribute.

E0081 A discriminant value is present more than once. Erroneous code example: ⓘ This example deliberately fails to compile enum Enum { P = 3 , X = 3 , Y = 5 , } Run Enum discriminants are used to differentiate enum variants stored in memory. This error indicates that the same value was used for two or more variants, making it impossible to distinguish them. enum Enum { P , X = 3 , Y = 5 , } Run Note that variants without a manually specified discriminant are numbered from top to bottom starting from 0, so clashes can occur with seemingly unrelated variants. ⓘ This example deliberately fails to compile enum Bad { X , Y = 0 , } Run Here X will have already been specified the discriminant 0 by the time Y is encountered, so a conflict occurs.

E0084 An unsupported representation was attempted on a zero-variant enum. Erroneous code example: ⓘ This example deliberately fails to compile #[ repr ( i32 )] enum NightsWatch {} Run It is impossible to define an integer type to be used to represent zero-variant enum values because there are no zero-variant enum values. There is no way to construct an instance of the following type using only safe code. So you have two solutions. Either you add variants in your enum: #[ repr ( i32 )] enum NightsWatch { JonSnow , Commander , } Run or you remove the integer representation of your enum: enum NightsWatch {} Run

E0087 Note: this error code is no longer emitted by the compiler. Too many type arguments were supplied for a function. For example: ⓘ This example deliberately fails to compile fn foo < T > () {} fn main () { foo :: < f64 , bool > (); } Run The number of supplied arguments must exactly match the number of defined type parameters.

E0088 Note: this error code is no longer emitted by the compiler. You gave too many lifetime arguments. Erroneous code example: ⓘ This example deliberately fails to compile fn f () {} fn main () { f :: < 'static > () } Run Please check you give the right number of lifetime arguments. Example: fn f () {} fn main () { f () } Run It's also important to note that the Rust compiler can generally determine the lifetime by itself. Example: struct Foo { value : String } impl Foo { fn get_value < 'a > ( & 'a self ) - > & 'a str { & self . value } fn without_lifetime ( & self ) - > & str { & self . value } } fn main () { let f = Foo { value : "hello" . to_owned () }; println ! ( "{}" , f . get_value ()); println ! ( "{}" , f . without_lifetime ()); } Run

E0089 Note: this error code is no longer emitted by the compiler. Too few type arguments were supplied for a function. For example: ⓘ This example deliberately fails to compile fn foo < T , U > () {} fn main () { foo :: < f64 > (); } Run Note that if a function takes multiple type arguments but you want the compiler to infer some of them, you can use type placeholders: ⓘ This example deliberately fails to compile fn foo < T , U > ( x : T ) {} fn main () { let x : bool = true ; foo :: < f64 > ( x ); foo :: < _ , f64 > ( x ); } Run

E0091 An unnecessary type or const parameter was given in a type alias. Erroneous code example: ⓘ This example deliberately fails to compile type Foo < T > = u32 ; type Foo < A , B > = Box < A > ; Run Please check you didn't write too many parameters. Example: type Foo = u32 ; type Foo2 < A > = Box < A > ; Run

E0092 An undefined atomic operation function was declared. Erroneous code example: ⓘ This example deliberately fails to compile #![ feature ( intrinsics )] extern "rust-intrinsic" { fn atomic_foo (); } Run Please check you didn't make a mistake in the function's name. All intrinsic functions are defined in librustc_codegen_llvm/intrinsic.rs and in libcore/intrinsics.rs in the Rust source code. Example: #![ feature ( intrinsics )] extern "rust-intrinsic" { fn atomic_fence (); } Run

E0093 An unknown intrinsic function was declared. Erroneous code example: ⓘ This example deliberately fails to compile #![ feature ( intrinsics )] extern "rust-intrinsic" { fn foo (); } fn main () { unsafe { foo (); } } Run Please check you didn't make a mistake in the function's name. All intrinsic functions are defined in librustc_codegen_llvm/intrinsic.rs and in libcore/intrinsics.rs in the Rust source code. Example: #![ feature ( intrinsics )] extern "rust-intrinsic" { fn atomic_fence (); } fn main () { unsafe { atomic_fence (); } } Run

E0094 An invalid number of type parameters was given to an intrinsic function. Erroneous code example: ⓘ This example deliberately fails to compile #![ feature ( intrinsics )] extern "rust-intrinsic" { fn size_of < T , U > () - > usize ; } Run Please check that you provided the right number of type parameters and verify with the function declaration in the Rust source code. Example: #![ feature ( intrinsics )] extern "rust-intrinsic" { fn size_of < T > () - > usize ; } Run

E0106 This error indicates that a lifetime is missing from a type. If it is an error inside a function signature, the problem may be with failing to adhere to the lifetime elision rules (see below). Erroneous code examples: ⓘ This example deliberately fails to compile struct Foo1 { x : & bool } struct Foo2 < 'a > { x : & 'a bool } struct Bar1 { x : Foo2 } struct Bar2 < 'a > { x : Foo2 < 'a > } enum Baz1 { A ( u8 ), B ( & bool ), } enum Baz2 < 'a > { A ( u8 ), B ( & 'a bool ), } type MyStr1 = & str ; type MyStr2 < 'a > = & 'a str ; Run Lifetime elision is a special, limited kind of inference for lifetimes in function signatures which allows you to leave out lifetimes in certain cases. For more background on lifetime elision see the book. The lifetime elision rules require that any function signature with an elided output lifetime must either have: exactly one input lifetime

or, multiple input lifetimes, but the function must also be a method with a &self or &mut self receiver In the first case, the output lifetime is inferred to be the same as the unique input lifetime. In the second case, the lifetime is instead inferred to be the same as the lifetime on &self or &mut self . Here are some examples of elision errors: ⓘ This example deliberately fails to compile fn foo () - > & str { } fn bar ( x : & str , y : & str ) - > & str { } fn baz < 'a > ( x : & 'a str , y : & str ) - > & str { } Run

E0107 An incorrect number of generic arguments were provided. Erroneous code example: ⓘ This example deliberately fails to compile struct Foo < T > { x : T } struct Bar { x : Foo } struct Baz < S , T > { x : Foo < S , T > } fn foo < T , U > ( x : T , y : U ) {} fn f () {} fn main () { let x : bool = true ; foo :: < bool > ( x ); foo :: < bool , i32 , i32 > ( x , 2 , 4 ); f :: < 'static > (); } Run When using/declaring an item with generic arguments, you must provide the exact same number: struct Foo < T > { x : T } struct Bar < T > { x : Foo < T > } struct Baz < S , T > { x : Foo < S > , y : Foo < T > } fn foo < T , U > ( x : T , y : U ) {} fn f () {} fn main () { let x : bool = true ; foo :: < bool , u32 > ( x , 12 ); f (); } Run

E0109 You tried to provide a generic argument to a type which doesn't need it. Erroneous code example: ⓘ This example deliberately fails to compile type X = u32 < i32 > ; type Y = bool < 'static > ; Run Check that you used the correct argument and that the definition is correct. Example: type X = u32 ; type Y = bool ; Run Note that generic arguments for enum variant constructors go after the variant, not after the enum. For example, you would write Option::None::<u32> , rather than Option::<u32>::None .

E0110 Note: this error code is no longer emitted by the compiler. You tried to provide a lifetime to a type which doesn't need it. See E0109 for more details.

E0116 An inherent implementation was defined for a type outside the current crate. Erroneous code example: ⓘ This example deliberately fails to compile impl Vec < u8 > { } Run You can only define an inherent implementation for a type in the same crate where the type was defined. For example, an impl block as above is not allowed since Vec is defined in the standard library. To fix this problem, you can do either of these things: define a trait that has the desired associated functions/types/constants and implement the trait for the type in question

define a new type wrapping the type and define an implementation on the new type Note that using the type keyword does not work here because type only introduces a type alias: ⓘ This example deliberately fails to compile type Bytes = Vec < u8 > ; impl Bytes { } Run

E0117 Only traits defined in the current crate can be implemented for arbitrary types. Erroneous code example: ⓘ This example deliberately fails to compile impl Drop for u32 {} Run This error indicates a violation of one of Rust's orphan rules for trait implementations. The rule prohibits any implementation of a foreign trait (a trait defined in another crate) where the type that is implementing the trait is foreign

all of the parameters being passed to the trait (if there are any) are also foreign. To avoid this kind of error, ensure that at least one local type is referenced by the impl : pub struct Foo ; impl Drop for Foo { } impl From < Foo > for i32 { fn from ( i : Foo ) - > i32 { 0 } } Run Alternatively, define a trait locally and implement that instead: trait Bar { fn get ( & self ) - > usize ; } impl Bar for u32 { fn get ( & self ) - > usize { 0 } } Run For information on the design of the orphan rules, see RFC 1023.

E0118 An inherent implementation was defined for something which isn't a struct nor an enum. Erroneous code example: ⓘ This example deliberately fails to compile impl ( u8 , u8 ) { fn get_state ( & self ) - > String { } } Run To fix this error, please implement a trait on the type or wrap it in a struct. Example: trait LiveLongAndProsper { fn get_state ( & self ) - > String ; } impl LiveLongAndProsper for ( u8 , u8 ) { fn get_state ( & self ) - > String { "He's dead, Jim!" . to_owned () } } Run Alternatively, you can create a newtype. A newtype is a wrapping tuple-struct. For example, NewType is a newtype over Foo in struct NewType(Foo) . Example: struct TypeWrapper (( u8 , u8 )); impl TypeWrapper { fn get_state ( & self ) - > String { "Fascinating!" . to_owned () } } Run

E0119 There are conflicting trait implementations for the same type. Erroneous code example: ⓘ This example deliberately fails to compile trait MyTrait { fn get ( & self ) - > usize ; } impl < T > MyTrait for T { fn get ( & self ) - > usize { 0 } } struct Foo { value : usize } impl MyTrait for Foo { fn get ( & self ) - > usize { self . value } } Run When looking for the implementation for the trait, the compiler finds both the impl<T> MyTrait for T where T is all types and the impl MyTrait for Foo . Since a trait cannot be implemented multiple times, this is an error. So, when you write: trait MyTrait { fn get ( & self ) - > usize ; } impl < T > MyTrait for T { fn get ( & self ) - > usize { 0 } } Run This makes the trait implemented on all types in the scope. So if you try to implement it on another one after that, the implementations will conflict. Example: trait MyTrait { fn get ( & self ) - > usize ; } impl < T > MyTrait for T { fn get ( & self ) - > usize { 0 } } struct Foo ; fn main () { let f = Foo ; f . get (); } Run

E0120 Drop was implemented on a trait, which is not allowed: only structs and enums can implement Drop. Erroneous code example: ⓘ This example deliberately fails to compile trait MyTrait {} impl Drop for MyTrait { fn drop ( & mut self ) {} } Run A workaround for this problem is to wrap the trait up in a struct, and implement Drop on that: trait MyTrait {} struct MyWrapper < T : MyTrait > { foo : T } impl < T : MyTrait > Drop for MyWrapper < T > { fn drop ( & mut self ) {} } Run Alternatively, wrapping trait objects requires something: trait MyTrait {} struct MyWrapper < 'a > { foo : & 'a MyTrait } impl < 'a > Drop for MyWrapper < 'a > { fn drop ( & mut self ) {} } Run

E0121 The type placeholder _ was used within a type on an item's signature. Erroneous code example: ⓘ This example deliberately fails to compile fn foo () - > _ { 5 } static BAR : _ = "test" ; Run In those cases, you need to provide the type explicitly: fn foo () - > i32 { 5 } static BAR : & str = "test" ; Run The type placeholder _ can be used outside item's signature as follows: let x = "a4a" . split ( '4' ) . collect :: < Vec < _ > > (); Run

E0124 A struct was declared with two fields having the same name. Erroneous code example: ⓘ This example deliberately fails to compile struct Foo { field1 : i32 , field1 : i32 , } Run Please verify that the field names have been correctly spelled. Example: struct Foo { field1 : i32 , field2 : i32 , } Run

E0128 A type parameter with default value is using forward declared identifier. Erroneous code example: ⓘ This example deliberately fails to compile struct Foo < T = U , U = () > { field1 : T , field2 : U , } Run Type parameter defaults can only use parameters that occur before them. Since type parameters are evaluated in-order, this issue could be fixed by doing: struct Foo < U = (), T = U > { field1 : T , field2 : U , } Run Please also verify that this wasn't because of a name-clash and rename the type parameter if so.

E0130 A pattern was declared as an argument in a foreign function declaration. Erroneous code example: ⓘ This example deliberately fails to compile extern { fn foo (( a , b ): ( u32 , u32 )); } Run To fix this error, replace the pattern argument with a regular one. Example: struct SomeStruct { a : u32 , b : u32 , } extern { fn foo ( s : SomeStruct ); } Run Or: extern { fn foo ( a : ( u32 , u32 )); } Run

E0131 The main function was defined with generic parameters. Erroneous code example: ⓘ This example deliberately fails to compile fn main < T > () { } Run It is not possible to define the main function with generic parameters. It must not take any arguments.

E0132 A function with the start attribute was declared with type parameters. Erroneous code example: ⓘ This example deliberately fails to compile #![ feature ( start )] #[ start ] fn f < T > () {} Run It is not possible to declare type parameters on a function that has the start attribute. Such a function must have the following type signature (for more information, view the unstable book): fn ( isize , * const * const u8 ) - > isize ; Run Example: #![ feature ( start )] #[ start ] fn my_start ( argc : isize , argv : * const * const u8 ) - > isize { 0 } Run

E0133 Unsafe code was used outside of an unsafe function or block. Erroneous code example: ⓘ This example deliberately fails to compile unsafe fn f () { return ; } fn main () { f (); } Run Using unsafe functionality is potentially dangerous and disallowed by safety checks. Examples: Dereferencing raw pointers

Calling functions via FFI

Calling functions marked unsafe These safety checks can be relaxed for a section of the code by wrapping the unsafe instructions with an unsafe block. For instance: unsafe fn f () { return ; } fn main () { unsafe { f (); } } Run See the unsafe section of the Book for more details.

E0136 More than one main function was found. Erroneous code example: ⓘ This example deliberately fails to compile fn main () { } fn main () { } Run A binary can only have one entry point, and by default that entry point is the main() function. If there are multiple instances of this function, please rename one of them.

E0137 More than one function was declared with the #[main] attribute. Erroneous code example: ⓘ This example deliberately fails to compile #![ feature ( main )] #[ main ] fn foo () {} #[ main ] fn f () {} Run This error indicates that the compiler found multiple functions with the #[main] attribute. This is an error because there must be a unique entry point into a Rust program. Example: #![ feature ( main )] #[ main ] fn f () {} Run

E0138 More than one function was declared with the #[start] attribute. Erroneous code example: ⓘ This example deliberately fails to compile #![ feature ( start )] #[ start ] fn foo ( argc : isize , argv : * const * const u8 ) - > isize {} #[ start ] fn f ( argc : isize , argv : * const * const u8 ) - > isize {} Run This error indicates that the compiler found multiple functions with the #[start] attribute. This is an error because there must be a unique entry point into a Rust program. Example: #![ feature ( start )] #[ start ] fn foo ( argc : isize , argv : * const * const u8 ) - > isize { 0 } Run

E0139 Note: this error code is no longer emitted by the compiler. There are various restrictions on transmuting between types in Rust; for example types being transmuted must have the same size. To apply all these restrictions, the compiler must know the exact types that may be transmuted. When type parameters are involved, this cannot always be done. So, for example, the following is not allowed: use std :: mem :: transmute ; struct Foo < T > ( Vec < T > ); fn foo < T > ( x : Vec < T > ) { let y : Foo < T > = unsafe { transmute ( x ) }; } Run In this specific case there's a good chance that the transmute is harmless (but this is not guaranteed by Rust). However, when alignment and enum optimizations come into the picture, it's quite likely that the sizes may or may not match with different type parameter substitutions. It's not possible to check this for all possible types, so transmute() simply only accepts types without any unsubstituted type parameters. If you need this, there's a good chance you're doing something wrong. Keep in mind that Rust doesn't guarantee much about the layout of different structs (even two structs with identical declarations may have different layouts). If there is a solution that avoids the transmute entirely, try it instead. If it's possible, hand-monomorphize the code by writing the function for each possible type substitution. It's possible to use traits to do this cleanly, for example: use std :: mem :: transmute ; struct Foo < T > ( Vec < T > ); trait MyTransmutableType : Sized { fn transmute ( _ : Vec < Self > ) - > Foo < Self > ; } impl MyTransmutableType for u8 { fn transmute ( x : Vec < u8 > ) - > Foo < u8 > { unsafe { transmute ( x ) } } } impl MyTransmutableType for String { fn transmute ( x : Vec < String > ) - > Foo < String > { unsafe { transmute ( x ) } } } fn foo < T : MyTransmutableType > ( x : Vec < T > ) { let y : Foo < T > = < T as MyTransmutableType > :: transmute ( x ); } Run Each impl will be checked for a size match in the transmute as usual, and since there are no unbound type parameters involved, this should compile unless there is a size mismatch in one of the impls. It is also possible to manually transmute: unsafe { ptr :: read ( & v as * const _ as * const SomeType ) } Run Note that this does not move v (unlike transmute ), and may need a call to mem::forget(v) in case you want to avoid destructors being called.

E0152 A lang item was redefined. Erroneous code example: ⓘ This example deliberately fails to compile #![ feature ( lang_items )] #[ lang = "owned_box" ] struct Foo ; Run Lang items are already implemented in the standard library. Unless you are writing a free-standing application (e.g., a kernel), you do not need to provide them yourself. You can build a free-standing crate by adding #![no_std] to the crate attributes: ⓘ This example is not tested #![ no_std ] Run See also the unstable book.

E0154 Note: this error code is no longer emitted by the compiler. Imports ( use statements) are not allowed after non-item statements, such as variable declarations and expression statements. Here is an example that demonstrates the error: fn f () { let x = 0 ; use std :: io :: Read ; } Run The solution is to declare the imports at the top of the block, function, or file. Here is the previous example again, with the correct order: fn f () { use std :: io :: Read ; let x = 0 ; } Run See the Declaration Statements section of the reference for more information about what constitutes an item declaration and what does not.

E0158 An associated const has been referenced in a pattern. Erroneous code example: ⓘ This example deliberately fails to compile enum EFoo { A , B , C , D } trait Foo { const X : EFoo ; } fn test < A : Foo > ( arg : EFoo ) { match arg { A :: X = > { println ! ( "A::X" ); } } } Run const and static mean different things. A const is a compile-time constant, an alias for a literal value. This property means you can match it directly within a pattern. The static keyword, on the other hand, guarantees a fixed location in memory. This does not always mean that the value is constant. For example, a global mutex can be declared static as well. If you want to match against a static , consider using a guard instead: static FORTY_TWO : i32 = 42 ; match Some ( 42 ) { Some ( x ) if x = = FORTY_TWO = > {} _ = > {} } Run

E0161 A value was moved whose size was not known at compile time. Erroneous code example: ⓘ This example deliberately fails to compile #![ feature ( box_syntax )] fn main () { let array : & [ isize ] = & [ 1 , 2 , 3 ]; let _x : Box < [ isize ] > = box * array ; } Run In Rust, you can only move a value when its size is known at compile time. To work around this restriction, consider "hiding" the value behind a reference: either &x or &mut x . Since a reference has a fixed size, this lets you move it around as usual. Example: #![ feature ( box_syntax )] fn main () { let array : & [ isize ] = & [ 1 , 2 , 3 ]; let _x : Box < & [ isize ] > = box array ; } Run

E0162 Note: this error code is no longer emitted by the compiler. An if-let pattern attempts to match the pattern, and enters the body if the match was successful. If the match is irrefutable (when it cannot fail to match), use a regular let -binding instead. For instance: struct Irrefutable ( i32 ); let irr = Irrefutable ( 0 ); if let Irrefutable ( x ) = irr { } Run Try this instead: struct Irrefutable ( i32 ); let irr = Irrefutable ( 0 ); let Irrefutable ( x ) = irr ; println ! ( "{}" , x ); Run

E0164 Something which is neither a tuple struct nor a tuple variant was used as a pattern. Erroneous code example: ⓘ This example deliberately fails to compile enum A { B , C , } impl A { fn new () {} } fn bar ( foo : A ) { match foo { A :: new () = > (), _ = > {} } } Run This error means that an attempt was made to match something which is neither a tuple struct nor a tuple variant. Only these two elements are allowed as a pattern: enum A { B , C , } impl A { fn new () {} } fn bar ( foo : A ) { match foo { A :: B = > (), _ = > {} } } Run

E0165 Note: this error code is no longer emitted by the compiler. A while-let pattern attempts to match the pattern, and enters the body if the match was successful. If the match is irrefutable (when it cannot fail to match), use a regular let -binding inside a loop instead. For instance: struct Irrefutable ( i32 ); let irr = Irrefutable ( 0 ); while let Irrefutable ( x ) = irr { } Run Try this instead: struct Irrefutable ( i32 ); let irr = Irrefutable ( 0 ); loop { let Irrefutable ( x ) = irr ; } Run

E0170 A pattern binding is using the same name as one of the variants of a type. Erroneous code example: ⓘ This example deliberately fails to compile enum Method { GET , POST , } fn is_empty ( s : Method ) - > bool { match s { GET = > true , _ = > false } } fn main () {} Run Enum variants are qualified by default. For example, given this type: enum Method { GET , POST , } Run You would match it using: enum Method { GET , POST , } let m = Method :: GET ; match m { Method :: GET = > {}, Method :: POST = > {}, } Run If you don't qualify the names, the code will bind new variables named "GET" and "POST" instead. This behavior is likely not what you want, so rustc warns when that happens. Qualified names are good practice, and most code works well with them. But if you prefer them unqualified, you can import the variants into scope: use Method :: * ; enum Method { GET , POST } Run If you want others to be able to import variants from your module directly, use pub use : pub use Method :: * ; pub enum Method { GET , POST } Run

E0178 The + type operator was used in an ambiguous context. Erroneous code example: ⓘ This example deliberately fails to compile trait Foo {} struct Bar < 'a > { x : & 'a Foo + 'a , y : & 'a mut Foo + 'a , z : fn () - > Foo + 'a , } Run In types, the + type operator has low precedence, so it is often necessary to use parentheses: trait Foo {} struct Bar < 'a > { x : & 'a ( Foo + 'a ), y : & 'a mut ( Foo + 'a ), z : fn () - > ( Foo + 'a ), } Run More details can be found in RFC 438.

E0183 No description.

E0184 The Copy trait was implemented on a type with a Drop implementation. Erroneous code example: ⓘ This example deliberately fails to compile #[ derive ( Copy )] struct Foo ; impl Drop for Foo { fn drop ( & mut self ) { } } Run Explicitly implementing both Drop and Copy trait on a type is currently disallowed. This feature can make some sense in theory, but the current implementation is incorrect and can lead to memory unsafety (see issue #20126), so it has been disabled for now.

E0185 An associated function for a trait was defined to be static, but an implementation of the trait declared the same function to be a method (i.e., to take a self parameter). Erroneous code example: ⓘ This example deliberately fails to compile trait Foo { fn foo (); } struct Bar ; impl Foo for Bar { fn foo ( & self ) {} } Run When a type implements a trait's associated function, it has to use the same signature. So in this case, since Foo::foo does not take any argument and does not return anything, its implementation on Bar should be the same: trait Foo { fn foo (); } struct Bar ; impl Foo for Bar { fn foo () {} } Run

E0186 An associated function for a trait was defined to be a method (i.e., to take a self parameter), but an implementation of the trait declared the same function to be static. Erroneous code example: ⓘ This example deliberately fails to compile trait Foo { fn foo ( & self ); } struct Bar ; impl Foo for Bar { fn foo () {} } Run When a type implements a trait's associated function, it has to use the same signature. So in this case, since Foo::foo takes self as argument and does not return anything, its implementation on Bar should be the same: trait Foo { fn foo ( & self ); } struct Bar ; impl Foo for Bar { fn foo ( & self ) {} } Run

E0191 An associated type wasn't specified for a trait object. Erroneous code example: ⓘ This example deliberately fails to compile trait Trait { type Bar ; } type Foo = Trait ; Run Trait objects need to have all associated types specified. Please verify that all associated types of the trait were specified and the correct trait was used. Example: trait Trait { type Bar ; } type Foo = Trait < Bar = i32 > ; Run

E0193 Note: this error code is no longer emitted by the compiler. where clauses must use generic type parameters: it does not make sense to use them otherwise. An example causing this error: trait Foo { fn bar ( & self ); } #[ derive ( Copy , Clone )] struct Wrapper < T > { Wrapped : T } impl Foo for Wrapper < u32 > where Wrapper < u32 > : Clone { fn bar ( & self ) { } } Run This use of a where clause is strange - a more common usage would look something like the following: trait Foo { fn bar ( & self ); } #[ derive ( Copy , Clone )] struct Wrapper < T > { Wrapped : T } impl < T > Foo for Wrapper < T > where Wrapper < T > : Clone { fn bar ( & self ) { } } Run Here, we're saying that the implementation exists on Wrapper only when the wrapped type T implements Clone . The where clause is important because some types will not implement Clone , and thus will not get this method. In our erroneous example, however, we're referencing a single concrete type. Since we know for certain that Wrapper<u32> implements Clone , there's no reason to also specify it in a where clause.

E0195 The lifetime parameters of the method do not match the trait declaration. Erroneous code example: ⓘ This example deliberately fails to compile trait Trait { fn bar < 'a , 'b : 'a > ( x : & 'a str , y : & 'b str ); } struct Foo ; impl Trait for Foo { fn bar < 'a , 'b > ( x : & 'a str , y : & 'b str ) { } } Run The lifetime constraint 'b for bar() implementation does not match the trait declaration. Ensure lifetime declarations match exactly in both trait declaration and implementation. Example: trait Trait { fn t < 'a , 'b : 'a > ( x : & 'a str , y : & 'b str ); } struct Foo ; impl Trait for Foo { fn t < 'a , 'b : 'a > ( x : & 'a str , y : & 'b str ) { } } Run

E0197 An inherent implementation was marked unsafe. Erroneous code example: ⓘ This example deliberately fails to compile struct Foo ; unsafe impl Foo { } Run Inherent implementations (one that do not implement a trait but provide methods associated with a type) are always safe because they are not implementing an unsafe trait. Removing the unsafe keyword from the inherent implementation will resolve this error. struct Foo ; impl Foo { } Run

E0198 A negative implementation was marked as unsafe. Erroneous code example: ⓘ This example deliberately fails to compile struct Foo ; unsafe impl ! Clone for Foo { } Run A negative implementation is one that excludes a type from implementing a particular trait. Not being able to use a trait is always a safe operation, so negative implementations are always safe and never need to be marked as unsafe. This will compile: ⓘ This example is not tested #![ feature ( optin_builtin_traits )] struct Foo ; auto trait Enterprise {} impl ! Enterprise for Foo { } Run Please note that negative impls are only allowed for auto traits.

E0199 A trait implementation was marked as unsafe while the trait is safe. Erroneous code example: ⓘ This example deliberately fails to compile struct Foo ; trait Bar { } unsafe impl Bar for Foo { } Run Safe traits should not have unsafe implementations, therefore marking an implementation for a safe trait unsafe will cause a compiler error. Removing the unsafe marker on the trait noted in the error will resolve this problem: struct Foo ; trait Bar { } impl Bar for Foo { } Run

E0200 An unsafe trait was implemented without an unsafe implementation. Erroneous code example: ⓘ This example deliberately fails to compile struct Foo ; unsafe trait Bar { } impl Bar for Foo { } Run Unsafe traits must have unsafe implementations. This error occurs when an implementation for an unsafe trait isn't marked as unsafe. This may be resolved by marking the unsafe implementation as unsafe. struct Foo ; unsafe trait Bar { } unsafe impl Bar for Foo { } Run

E0201 Two associated items (like methods, associated types, associated functions, etc.) were defined with the same identifier. Erroneous code example: ⓘ This example deliberately fails to compile struct Foo ( u8 ); impl Foo { fn bar ( & self ) - > bool { self . 0 > 5 } fn bar () {} } trait Baz { type Quux ; fn baz ( & self ) - > bool ; } impl Baz for Foo { type Quux = u32 ; fn baz ( & self ) - > bool { true } fn baz ( & self ) - > bool { self . 0 > 5 } type Quux = u32 ; } Run Note, however, that items with the same name are allowed for inherent impl blocks that don't overlap: struct Foo < T > ( T ); impl Foo < u8 > { fn bar ( & self ) - > bool { self . 0 > 5 } } impl Foo < bool > { fn bar ( & self ) - > bool { self . 0 } } Run

E0202 Inherent associated types were part of RFC 195 but are not yet implemented. See the tracking issue for the status of this implementation. Erroneous code example: ⓘ This example deliberately fails to compile struct Foo ; impl Foo { type Bar = isize ; } Run

E0203 Having multiple relaxed default bounds is unsupported. Erroneous code example: ⓘ This example deliberately fails to compile struct Bad < T : ? Sized + ? Send > { inner : T } Run Here the type T cannot have a relaxed bound for multiple default traits ( Sized and Send ). This can be fixed by only using one relaxed bound. struct Good < T : ? Sized > { inner : T } Run

E0204 The Copy trait was implemented on a type which contains a field that doesn't implement the Copy trait. Erroneous code example: ⓘ This example deliberately fails to compile struct Foo { foo : Vec < u32 > , } impl Copy for Foo { } Run The Copy trait is implemented by default only on primitive types. If your type only contains primitive types, you'll be able to implement Copy on it. Otherwise, it won't be possible. Here's another example that will fail: ⓘ This example deliberately fails to compile #[ derive ( Copy )] struct Foo < 'a > { ty : & 'a mut bool , } Run This fails because &mut T is not Copy , even when T is Copy (this differs from the behavior for &T , which is always Copy ).

E0205 Note: this error code is no longer emitted by the compiler. An attempt to implement the Copy trait for an enum failed because one of the variants does not implement Copy . To fix this, you must implement Copy for the mentioned variant. Note that this may not be possible, as in the example of ⓘ This example deliberately fails to compile enum Foo { Bar ( Vec < u32 > ), Baz , } impl Copy for Foo { } Run This fails because Vec<T> does not implement Copy for any T . Here's another example that will fail: ⓘ This example deliberately fails to compile #[ derive ( Copy )] enum Foo < 'a > { Bar ( & 'a mut bool ), Baz , } Run This fails because &mut T is not Copy , even when T is Copy (this differs from the behavior for &T , which is always Copy ).

E0206 The Copy trait was implemented on a type which is neither a struct nor an enum. Erroneous code example: ⓘ This example deliberately fails to compile type Foo = [ u8 ; 256 ]; impl Copy for Foo { } #[ derive ( Copy , Clone )] struct Bar ; impl Copy for & 'static mut Bar { } Run You can only implement Copy for a struct or an enum. Both of the previous examples will fail, because neither [u8; 256] nor &'static mut Bar (mutable reference to Bar ) is a struct or enum.

E0207 A type parameter that is specified for impl is not constrained. Erroneous code example: ⓘ This example deliberately fails to compile struct Foo ; impl < T : Default > Foo { fn get ( & self ) - > T { < T as Default > :: default () } } Run Any type parameter parameter of an impl must meet at least one of the following criteria: it appears in the implementing type of the impl, e.g. impl<T> Foo<T>

for a trait impl, it appears in the implemented trait, e.g. impl<T> SomeTrait<T> for Foo

it is bound as an associated type, e.g. impl<T, U> SomeTrait for T where T: AnotherTrait<AssocType=U> Error example 1 Suppose we have a struct Foo and we would like to define some methods for it. The previous code example has a definition which leads to a compiler error: The problem is that the parameter T does not appear in the implementing type ( Foo ) of the impl. In this case, we can fix the error by moving the type parameter from the impl to the method get : struct Foo ; impl Foo { fn get < T : Default > ( & self ) - > T { < T as Default > :: default () } } Run Error example 2 As another example, suppose we have a Maker trait and want to establish a type FooMaker that makes Foo s: ⓘ This example deliberately fails to compile trait Maker { type Item ; fn make ( & mut self ) - > Self :: Item ; } struct Foo < T > { foo : T } struct FooMaker ; impl < T : Default > Maker for FooMaker { type Item = Foo < T > ; fn make ( & mut self ) - > Foo < T > { Foo { foo : < T as Default > :: default () } } } Run This fails to compile because T does not appear in the trait or in the implementing type. One way to work around this is to introduce a phantom type parameter into FooMaker , like so: use std :: marker :: PhantomData ; trait Maker { type Item ; fn make ( & mut self ) - > Self :: Item ; } struct Foo < T > { foo : T } struct FooMaker < T > { phantom : PhantomData < T > , } impl < T : Default > Maker for FooMaker < T > { type Item = Foo < T > ; fn make ( & mut self ) - > Foo < T > { Foo { foo : < T as Default > :: default (), } } } Run Another way is to do away with the associated type in Maker and use an input type parameter instead: trait Maker < Item > { fn make ( & mut self ) - > Item ; } struct Foo < T > { foo : T } struct FooMaker ; impl < T : Default > Maker < Foo < T > > for FooMaker { fn make ( & mut self ) - > Foo < T > { Foo { foo : < T as Default > :: default () } } } Run Additional information For more information, please see RFC 447.

E0208 No description.

E0210 This error indicates a violation of one of Rust's orphan rules for trait implementations. The rule concerns the use of type parameters in an implementation of a foreign trait (a trait defined in another crate), and states that type parameters must be "covered" by a local type. When implementing a foreign trait for a foreign type, the trait must have one or more type parameters. A type local to your crate must appear before any use of any type parameters. To understand what this means, it is perhaps easier to consider a few examples. If ForeignTrait is a trait defined in some external crate foo , then the following trait impl is an error: ⓘ This example deliberately fails to compile extern crate foo ; use foo :: ForeignTrait ; impl < T > ForeignTrait for T { } Run To work around this, it can be covered with a local type, MyType : struct MyType < T > ( T ); impl < T > ForeignTrait for MyType < T > { } Run Please note that a type alias is not sufficient. For another example of an error, suppose there's another trait defined in foo named ForeignTrait2 that takes two type parameters. Then this impl results in the same rule violation: ⓘ This example is not tested struct MyType2 ; impl < T > ForeignTrait2 < T , MyType < T > > for MyType2 { } Run The reason for this is that there are two appearances of type parameter T in the impl header, both as parameters for ForeignTrait2 . The first appearance is uncovered, and so runs afoul of the orphan rule. Consider one more example: ⓘ This example is not tested impl < T > ForeignTrait2 < MyType < T > , T > for MyType2 { } Run This only differs from the previous impl in that the parameters T and MyType<T> for ForeignTrait2 have been swapped. This example does not violate the orphan rule; it is permitted. To see why that last example was allowed, you need to understand the general rule. Unfortunately this rule is a bit tricky to state. Consider an impl : ⓘ This example is not tested impl < P1 , ..., Pm > ForeignTrait < T1 , ..., Tn > for T0 { ... } Run where P1, ..., Pm are the type parameters of the impl and T0, ..., Tn are types. One of the types T0, ..., Tn must be a local type (this is another orphan rule, see the explanation for E0117). Both of the following must be true: At least one of the types T0..=Tn must be a local type. Let Ti be the first such type. No uncovered type parameters P1..=Pm may appear in T0..Ti (excluding Ti ). For information on the design of the orphan rules, see RFC 2451 and RFC 1023. For information on the design of the orphan rules, see RFC 1023.

E0211 Note: this error code is no longer emitted by the compiler. You used a function or type which doesn't fit the requirements for where it was used. Erroneous code examples: ⓘ This example deliberately fails to compile #![ feature ( intrinsics )] extern "rust-intrinsic" { fn size_of < T > (); } fn main () - > i32 { 0 } let x = 1u8 ; match x { 0u8 .. = 3i8 = > (), _ = > () } use std :: rc :: Rc ; struct Foo ; impl Foo { fn x ( self : Rc < Foo > ) {} } Run For the first code example, please check the function definition. Example: #![ feature ( intrinsics )] extern "rust-intrinsic" { fn size_of < T > () - > usize ; } Run The second case example is a bit particular: the main function must always have this definition: ⓘ This example deliberately fails to compile fn main (); Run They never take parameters and never return types. For the third example, when you match, all patterns must have the same type as the type you're matching on. Example: let x = 1u8 ; match x { 0u8 .. = 3u8 = > (), _ = > () } Run And finally, for the last example, only Box<Self> , &Self , Self , or &mut Self work as explicit self parameters. Example: struct Foo ; impl Foo { fn x ( self : Box < Foo > ) {} } Run

E0212 No description.

E0214 A generic type was described using parentheses rather than angle brackets. Erroneous code example: ⓘ This example deliberately fails to compile let v : Vec ( & str ) = vec ! [ "foo" ]; Run This is not currently supported: v should be defined as Vec<&str> . Parentheses are currently only used with generic types when defining parameters for Fn -family traits. The previous code example fixed: let v : Vec < & str > = vec ! [ "foo" ]; Run

E0220 The associated type used was not defined in the trait. Erroneous code example: ⓘ This example deliberately fails to compile trait T1 { type Bar ; } type Foo = T1 < F = i32 > ; trait T2 { type Bar ; fn return_bool ( & self , _ : & Self :: Bar , _ : & Self :: Baz ) - > bool ; } Run Make sure that you have defined the associated type in the trait body. Also, verify that you used the right trait or you didn't misspell the associated type name. Example: trait T1 { type Bar ; } type Foo = T1 < Bar = i32 > ; trait T2 { type Bar ; type Baz ; fn return_bool ( & self , _ : & Self :: Bar , _ : & Self :: Baz ) - > bool ; } Run

E0221 An attempt was made to retrieve an associated type, but the type was ambiguous. Erroneous code example: ⓘ This example deliberately fails to compile trait T1 {} trait T2 {} trait Foo { type A : T1 ; } trait Bar : Foo { type A : T2 ; fn do_something () { let _ : Self :: A ; } } Run In this example, Foo defines an associated type A . Bar inherits that type from Foo , and defines another associated type of the same name. As a result, when we attempt to use Self::A , it's ambiguous whether we mean the A defined by Foo or the one defined by Bar . There are two options to work around this issue. The first is simply to rename one of the types. Alternatively, one can specify the intended type using the following syntax: trait T1 {} trait T2 {} trait Foo { type A : T1 ; } trait Bar : Foo { type A : T2 ; fn do_something () { let _ : < Self as Bar > :: A ; } } Run

E0222 An attempt was made to constrain an associated type. Erroneous code example: ⓘ This example deliberately fails to compile pub trait Vehicle { type Color ; } pub trait Box { type Color ; } pub trait BoxCar : Box + Vehicle {} fn dent_object < COLOR > ( c : dyn BoxCar < Color = COLOR > ) {} Run In this example, BoxCar has two super-traits: Vehicle and Box . Both of these traits define an associated type Color . BoxCar inherits two types with that name from both super-traits. Because of this, we need to use the fully qualified path syntax to refer to the appropriate Color associated type, either <BoxCar as Vehicle>::Color or <BoxCar as Box>::Color , but this syntax is not allowed to be used in a function signature. In order to encode this kind of constraint, a where clause and a new type parameter are needed: pub trait Vehicle { type Color ; } pub trait Box { type Color ; } pub trait BoxCar : Box + Vehicle {} fn foo < CAR , COLOR > ( c : CAR , ) where CAR : BoxCar , CAR : Vehicle < Color = COLOR > , CAR : Box < Color = COLOR > {} Run

E0223 An attempt was made to retrieve an associated type, but the type was ambiguous. Erroneous code example: ⓘ This example deliberately fails to compile trait MyTrait { type X ; } fn main () { let foo : MyTrait :: X ; } Run The problem here is that we're attempting to take the type of X from MyTrait. Unfortunately, the type of X is not defined, because it's only made concrete in implementations of the trait. A working version of this code might look like: trait MyTrait { type X ; } struct MyStruct ; impl MyTrait for MyStruct { type X = u32 ; } fn main () { let foo : < MyStruct as MyTrait > :: X ; } Run This syntax specifies that we want the X type from MyTrait, as made concrete in MyStruct. The reason that we cannot simply use MyStruct::X is that MyStruct might implement two different traits with identically-named associated types. This syntax allows disambiguation between the two.

E0224 A trait object was declaired with no traits. Erroneous code example: ⓘ This example deliberately fails to compile type Foo = dyn 'static + ; Run Rust does not currently support this. To solve ensure the the trait object has at least one trait: type Foo = dyn 'static + Copy ; Run

E0225 Multiple types were used as bounds for a closure or trait object. Erroneous code example: ⓘ This example deliberately fails to compile fn main () { let _ : Box < dyn std :: io :: Read + std :: io :: Write > ; } Run Rust does not currently support this. Auto traits such as Send and Sync are an exception to this rule: It's possible to have bounds of one non-builtin trait, plus any number of auto traits. For example, the following compiles correctly: fn main () { let _ : Box < dyn std :: io :: Read + Send + Sync > ; } Run

E0226 More than one explicit lifetime bound was used on a trait object. Example of erroneous code: ⓘ This example deliberately fails to compile trait Foo {} type T < 'a , 'b > = dyn Foo + 'a + 'b ; Run Here T is a trait object with two explicit lifetime bounds, 'a and 'b. Only a single explicit lifetime bound is permitted on trait objects. To fix this error, consider removing one of the lifetime bounds: trait Foo {} type T < 'a > = dyn Foo + 'a ; Run

E0227 No description.

E0228 The lifetime bound for this object type cannot be deduced from context and must be specified. Erroneous code example: ⓘ This example deliberately fails to compile trait Trait { } struct TwoBounds < 'a , 'b , T : Sized + 'a + 'b > { x : & 'a i32 , y : & 'b i32 , z : T , } type Foo < 'a , 'b > = TwoBounds < 'a , 'b , dyn Trait > ; Run When a trait object is used as a type argument of a generic type, Rust will try to infer its lifetime if unspecified. However, this isn't possible when the containing type has more than one lifetime bound. The above example can be resolved by either reducing the number of lifetime bounds to one or by making the trait object lifetime explicit, like so: trait Trait { } struct TwoBounds < 'a , 'b , T : Sized + 'a + 'b > { x : & 'a i32 , y : & 'b i32 , z : T , } type Foo < 'a , 'b > = TwoBounds < 'a , 'b , dyn Trait + 'b > ; Run For more information, see RFC 599 and its amendment RFC 1156.

E0229 An associated type binding was done outside of the type parameter declaration and where clause. Erroneous code example: ⓘ This example deliberately fails to compile pub trait Foo { type A ; fn boo ( & self ) - > < Self as Foo > :: A ; } struct Bar ; impl Foo for isize { type A = usize ; fn boo ( & self ) - > usize { 42 } } fn baz < I > ( x : & < I as Foo < A = Bar > > :: A ) {} Run To solve this error, please move the type bindings in the type parameter declaration: fn baz < I : Foo < A = Bar > > ( x : & < I as Foo > :: A ) {} Run Or in the where clause: fn baz < I > ( x : & < I as Foo > :: A ) where I : Foo < A = Bar > {} Run

E0230 The #[rustc_on_unimplemented] attribute lets you specify a custom error message for when a particular trait isn't implemented on a type placed in a position that needs that trait. For example, when the following code is compiled: ⓘ This example deliberately fails to compile #![ feature ( rustc_attrs )] #[ rustc_on_unimplemented = "error on `{Self}` with params `<{A},{B}>`" ] trait BadAnnotation < A > {} Run There will be an error about bool not implementing Index<u8> , followed by a note saying "the type bool cannot be indexed by u8 ". As you can see, you can specify type parameters in curly braces for substitution with the actual types (using the regular format string syntax) in a given situation. Furthermore, {Self} will substitute to the type (in this case, bool ) that we tried to use. This error appears when the curly braces contain an identifier which doesn't match with any of the type parameters or the string Self . This might happen if you misspelled a type parameter, or if you intended to use literal curly braces. If it is the latter, escape the curly braces with a second curly brace of the same type; e.g., a literal { is {{ .

E0231 The #[rustc_on_unimplemented] attribute lets you specify a custom error message for when a particular trait isn't implemented on a type placed in a position that needs that trait. For example, when the following code is compiled: ⓘ This example deliberately fails to compile #![ feature ( rustc_attrs )] #[ rustc_on_unimplemented = "error on `{Self}` with params `<{A},{}>`" ] trait BadAnnotation < A > {} Run there will be an error about bool not implementing Index<u8> , followed by a note saying "the type bool cannot be indexed by u8 ". As you can see, you can specify type parameters in curly braces for substitution with the actual types (using the regular format string syntax) in a given situation. Furthermore, {Self} will substitute to the type (in this case, bool ) that we tried to use. This error appears when the curly braces do not contain an identifier. Please add one of the same name as a type parameter. If you intended to use literal braces, use {{ and }} to escape them.

E0232 The #[rustc_on_unimplemented] attribute lets you specify a custom error message for when a particular trait isn't implemented on a type placed in a position that needs that trait. For example, when the following code is compiled: ⓘ This example deliberately fails to compile #![ feature ( rustc_attrs )] #[ rustc_on_unimplemented ( lorem = "" )] trait BadAnnotation {} Run there will be an error about bool not implementing Index<u8> , followed by a note saying "the type bool cannot be indexed by u8 ". For this to work, some note must be specified. An empty attribute will not do anything, please remove the attribute or add some helpful note for users of the trait.

E0243 Note: this error code is no longer emitted by the compiler. This error indicates that not enough type parameters were found in a type or trait. For example, the Foo struct below is defined to be generic in T , but the type parameter is missing in the definition of Bar : ⓘ This example deliberately fails to compile struct Foo < T > { x : T } struct Bar { x : Foo } Run

E0244 Note: this error code is no longer emitted by the compiler. This error indicates that too many type parameters were found in a type or trait. For example, the Foo struct below has no type parameters, but is supplied with two in the definition of Bar : ⓘ This example deliberately fails to compile struct Foo { x : bool } struct Bar < S , T > { x : Foo < S , T > } Run

E0251 Note: this error code is no longer emitted by the compiler. Two items of the same name cannot be imported without rebinding one of the items under a new local name. An example of this error: use foo :: baz ; use bar :: * ; fn main () {} mod foo { pub struct baz ; } mod bar { pub mod baz {} } Run

E0252 Two items of the same name cannot be imported without rebinding one of the items under a new local name. Erroneous code example: ⓘ This example deliberately fails to compile use foo :: baz ; use bar :: baz ; fn main () {} mod foo { pub struct baz ; } mod bar { pub mod baz {} } Run You can use aliases in order to fix this error. Example: use foo :: baz as foo_baz ; use bar :: baz ; fn main () {} mod foo { pub struct baz ; } mod bar { pub mod baz {} } Run Or you can reference the item with its parent: use bar :: baz ; fn main () { let x = foo :: baz ; } mod foo { pub struct baz ; } mod bar { pub mod baz {} } Run

E0253 Attempt was made to import an unimportable value. This can happen when trying to import a method from a trait. Erroneous code example: ⓘ This example deliberately fails to compile mod foo { pub trait MyTrait { fn do_something (); } } use foo :: MyTrait :: do_something ; fn main () {} Run It's invalid to directly import methods belonging to a trait or concrete type.

E0254 Attempt was made to import an item whereas an extern crate with this name has already been imported. Erroneous code example: ⓘ This example deliberately fails to compile extern crate core ; mod foo { pub trait core { fn do_something (); } } use foo :: core ; fn main () {} Run To fix this issue, you have to rename at least one of the two imports. Example: extern crate core as libcore ; mod foo { pub trait core { fn do_something (); } } use foo :: core ; fn main () {} Run

E0255 You can't import a value whose name is the same as another value defined in the module. Erroneous code example: ⓘ This example deliberately fails to compile use bar :: foo ; fn foo () {} mod bar { pub fn foo () {} } fn main () {} Run You can use aliases in order to fix this error. Example: use bar :: foo as bar_foo ; fn foo () {} mod bar { pub fn foo () {} } fn main () {} Run Or you can reference the item with its parent: fn foo () {} mod bar { pub fn foo () {} } fn main () { bar :: foo (); } Run

E0256 Note: this error code is no longer emitted by the compiler. You can't import a type or module when the name of the item being imported is the same as another type or submodule defined in the module. An example of this error: ⓘ This example deliberately fails to compile use foo :: Bar ; type Bar = u32 ; mod foo { pub mod Bar { } } fn main () {} Run

E0259 The name chosen for an external crate conflicts with another external crate that has been imported into the current module. Erroneous code example: ⓘ This example deliberately fails to compile extern crate core ; extern crate std as core ; fn main () {} Run The solution is to choose a different name that doesn't conflict with any external crate imported into the current module. Correct example: extern crate core ; extern crate std as other_name ; fn main () {} Run

E0260 The name for an item declaration conflicts with an external crate's name. Erroneous code example: ⓘ This example deliberately fails to compile extern crate core ; struct core ; fn main () {} Run There are two possible solutions: Solution #1: Rename the item. extern crate core ; struct xyz ; Run Solution #2: Import the crate with a different name. extern crate core as xyz ; struct abc ; Run See the Declaration Statements section of the reference for more information about what constitutes an item declaration and what does not.

E0261 An undeclared lifetime was used. Erroneous code example: ⓘ This example deliberately fails to compile fn foo ( x : & 'a str ) { } struct Foo { x : & 'a str , } Run These can be fixed by declaring lifetime parameters: struct Foo < 'a > { x : & 'a str , } fn foo < 'a > ( x : & 'a str ) {} Run Impl blocks declare lifetime parameters separately. You need to add lifetime parameters to an impl block if you're implementing a type that has a lifetime parameter of its own. For example: ⓘ This example deliberately fails to compile struct Foo < 'a > { x : & 'a str , } impl Foo < 'a > { fn foo < 'a > ( x : & 'a str ) {} } Run This is fixed by declaring the impl block like this: struct Foo < 'a > { x : & 'a str , } impl < 'a > Foo < 'a > { fn foo ( x : & 'a str ) {} } Run

E0262 An invalid name was used for a lifetime parameter. Erroneous code example: ⓘ This example deliberately fails to compile fn foo < 'static > ( x : & 'static str ) { } Run Declaring certain lifetime names in parameters is disallowed. For example, because the 'static lifetime is a special built-in lifetime name denoting the lifetime of the entire program, this is an error:

E0263 A lifetime was declared more than once in the same scope. Erroneous code example: ⓘ This example deliberately fails to compile fn foo < 'a , 'b , 'a > ( x : & 'a str , y : & 'b str , z : & 'a str ) { } Run Two lifetimes cannot have the same name. To fix this example, change the second 'a lifetime into something else ( 'c for example): fn foo < 'a , 'b , 'c > ( x : & 'a str , y : & 'b str , z : & 'c str ) { } Run

E0264 An unknown external lang item was used. Erroneous code example: ⓘ This example deliberately fails to compile #![ feature ( lang_items )] extern "C" { #[ lang = "cake" ] fn cake (); } Run A list of available external lang items is available in src/librustc_middle/middle/weak_lang_items.rs . Example: #![ feature ( lang_items )] extern "C" { #[ lang = "panic_impl" ] fn cake (); } Run

E0267 A loop keyword ( break or continue ) was used inside a closure but outside of any loop. Erroneous code example: ⓘ This example deliberately fails to compile let w = | | { break ; }; Run break and continue keywords can be used as normal inside closures as long as they are also contained within a loop. To halt the execution of a closure you should instead use a return statement. Example: let w = | | { for _ in 0 .. 10 { break ; } }; w (); Run

E0268 A loop keyword ( break or continue ) was used outside of a loop. Erroneous code example: ⓘ This example deliberately fails to compile fn some_func () { break ; } Run Without a loop to break out of or continue in, no sensible action can be taken. Please verify that you are using break and continue only in loops. Example: fn some_func () { for _ in 0 .. 10 { break ; } } Run

E0271 A type mismatched an associated type of a trait. Erroneous code example: ⓘ This example deliberately fails to compile trait Trait { type AssociatedType ; } fn foo < T > ( t : T ) where T : Trait < AssociatedType = u32 > { println ! ( "in foo" ); } impl Trait for i8 { type AssociatedType = & 'static str ; } foo ( 3_i8 ); Run This is because of a type mismatch between the associated type of some trait (e.g., T::Bar , where T implements trait Quux { type Bar; } ) and another type U that is required to be equal to T::Bar , but is not. Examples follow. Here is that same example again, with some explanatory comments: ⓘ This example deliberately fails to compile trait Trait { type AssociatedType ; } fn foo < T > ( t : T ) where T : Trait < AssociatedType = u32 > { println ! ( "in foo" ); } impl Trait for i8 { type AssociatedType = & 'static str ; } foo ( 3_i8 ); Run To avoid those issues, you have to make the types match correctly. So we can fix the previous examples like this: trait Trait { type AssociatedType ; } fn foo < T > ( t : T ) where T : Trait < AssociatedType = & 'static str > { println ! ( "in foo" ); } impl Trait for i8 { type AssociatedType = & 'static str ; } foo ( 3_i8 ); let vs = vec ! [ 1 , 2 , 3 , 4 ]; for v in & vs { match v { & 1 = > {} _ = > {} } } Run

E0275 An evaluation of a trait requirement overflowed. Erroneous code example: ⓘ This example deliberately fails to compile trait Foo {} struct Bar < T > ( T ); impl < T > Foo for T where Bar < T > : Foo {} Run This error occurs when there was a recursive trait requirement that overflowed before it could be evaluated. This often means that there is an unbounded recursion in resolving some type bounds. To determine if a T is Foo , we need to check if Bar<T> is Foo . However, to do this check, we need to determine that Bar<Bar<T>> is Foo . To determine this, we check if Bar<Bar<Bar<T>>> is Foo , and so on. This is clearly a recursive requirement that can't be resolved directly. Consider changing your trait bounds so that they're less self-referential.

E0276 A trait implementation has stricter requirements than the trait definition. Erroneous code example: ⓘ This example deliberately fails to compile trait Foo { fn foo < T > ( x : T ); } impl Foo for bool { fn foo < T > ( x : T ) where T : Copy {} } Run Here, all types implementing Foo must have a method foo<T>(x: T) which can take any type T . However, in the impl for bool , we have added an extra bound that T is Copy , which isn't compatible with the original trait. Consider removing the bound from the method or adding the bound to the original method definition in the trait.

E0277 You tried to use a type which doesn't implement some trait in a place which expected that trait. Erroneous code example: ⓘ This example deliberately fails to compile trait Foo { fn bar ( & self ); } fn some_func < T : Foo > ( foo : T ) { foo . bar (); } fn main () { some_func ( 5i32 ); } Run In order to fix this error, verify that the type you're using does implement the trait. Example: trait Foo { fn bar ( & self ); } fn some_func < T : Foo > ( foo : T ) { foo . bar (); } impl Foo for i32 { fn bar ( & self ) {} } fn main () { some_func ( 5i32 ); } Run Or in a generic context, an erroneous code example would look like: ⓘ This example deliberately fails to compile fn some_func < T > ( foo : T ) { println ! ( "{:?}" , foo ); } fn main () { some_func ( 5i32 ); } Run Note that the error here is in the definition of the generic function: Although we only call it with a parameter that does implement Debug , the compiler still rejects the function: It must work with all possible input types. In order to make this example compile, we need to restrict the generic type we're accepting: use std :: fmt ; fn some_func < T : fmt :: Debug > ( foo : T ) { println ! ( "{:?}" , foo ); } fn main () { some_func ( 5i32 ); } Run Rust only looks at the signature of the called function, as such it must already specify all requirements that will be used for every type parameter.

E0279 No description.

E0280 No description.

E0281 Note: this error code is no longer emitted by the compiler. You tried to supply a type which doesn't implement some trait in a location which expected that trait. This error typically occurs when working with Fn -based types. Erroneous code example: ⓘ This example deliberately fails to compile fn foo < F : Fn ( usize ) > ( x : F ) { } fn main () { foo ( | y : String | { }); } Run The issue in this case is that foo is defined as accepting a Fn with one argument of type String , but the closure we attempted to pass to it requires one arguments of type usize .

E0282 The compiler could not infer a type and asked for a type annotation. Erroneous code example: ⓘ This example deliberately fails to compile let x = "hello" . chars (). rev (). collect (); Run This error indicates that type inference did not result in one unique possible type, and extra information is required. In most cases this can be provided by adding a type annotation. Sometimes you need to specify a generic type parameter manually. A common example is the collect method on Iterator . It has a generic type parameter with a FromIterator bound, which for a char iterator is implemented by Vec and String among others. Consider the following snippet that reverses the characters of a string: In the first code example, the compiler cannot infer what the type of x should be: Vec<char> and String are both suitable candidates. To specify which type to use, you can use a type annotation on x : let x : Vec < char > = "hello" . chars (). rev (). collect (); Run It is not necessary to annotate the full type. Once the ambiguity is resolved, the compiler can infer the rest: let x : Vec < _ > = "hello" . chars (). rev (). collect (); Run Another way to provide the compiler with enough information, is to specify the generic type parameter: let x = "hello" . chars (). rev (). collect :: < Vec < char > > (); Run Again, you need not specify the full type if the compiler can infer it: let x = "hello" . chars (). rev (). collect :: < Vec < _ > > (); Run Apart from a method or function with a generic type parameter, this error can occur when a type parameter of a struct or trait cannot be inferred. In that case it is not always possible to use a type annotation, because all candidates have the same return type. For instance: ⓘ This example deliberately fails to compile struct Foo < T > { num : T , } impl < T > Foo < T > { fn bar () - > i32 { 0 } fn baz () { let number = Foo :: bar (); } } Run This will fail because the compiler does not know which instance of Foo to call bar on. Change Foo::bar() to Foo::<T>::bar() to resolve the error.

E0283 An implementation cannot be chosen unambiguously because of lack of information. Erroneous code example: ⓘ This example deliberately fails to compile trait Generator { fn create () - > u32 ; } struct Impl ; impl Generator for Impl { fn create () - > u32 { 1 } } struct AnotherImpl ; impl Generator for AnotherImpl { fn create () - > u32 { 2 } } fn main () { let cont : u32 = Generator :: create (); } Run This error can be solved by adding type annotations that provide the missing information to the compiler. In this case, the solution is to use a concrete type: trait Generator { fn create () - > u32 ; } struct AnotherImpl ; impl Generator for AnotherImpl { fn create () - > u32 { 2 } } fn main () { let gen1 = AnotherImpl :: create (); let gen2 = < AnotherImpl as Generator > :: create (); } Run

E0284 This error occurs when the compiler is unable to unambiguously infer the return type of a function or method which is generic on return type, such as the collect method for Iterator s. For example: ⓘ This example deliberately fails to compile fn foo () - > Result < bool , () > { let results = [ Ok ( true ), Ok ( false ), Err (())]. iter (). cloned (); let v : Vec < bool > = results . collect () ? ; Ok ( true ) } Run Here we have an iterator results over Result<bool, ()> . Hence, results.collect() can return any type implementing FromIterator<Result<bool, ()>> . On the other hand, the ? operator can accept any type implementing Try . The author of this code probably wants collect() to return a Result<Vec<bool>, ()> , but the compiler can't be sure that there isn't another type T implementing both Try and FromIterator<Result<bool, ()>> in scope such that T::Ok == Vec<bool> . Hence, this code is ambiguous and an error is returned. To resolve this error, use a concrete type for the intermediate expression: fn foo () - > Result < bool , () > { let results = [ Ok ( true ), Ok ( false ), Err (())]. iter (). cloned (); let v = { 