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 => {/* ... */} // This handles the `None` case
    _ => {/* ... */} // All possible cases have already been handled
}

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 {
        // empty
    }
}

However, this won’t:

fn foo(x: Option<String>) {
    match x {
        // empty
    }
}

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:

enum Terminator {
    HastaLaVistaBaby,
    TalkToMyHand,
}

let x = Terminator::HastaLaVistaBaby;

match x { // error: non-exhaustive patterns: `HastaLaVistaBaby` not covered
    Terminator::TalkToMyHand => {}
}

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 => {}
}

// or:

match x {
    Terminator::TalkToMyHand => {}
    _ => {}
}

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:

let x = Some(1);
let Some(y) = x;
// error: refutable pattern in local binding: `None` not covered

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) => {
        // do something
    },
    None => {}
}

// or:

if let Some(y) = x {
    // do something
}

E0007

Note: this error code is no longer emitted by the compiler.

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:

#![feature(bindings_after_at)]

let x = Some("s".to_string());

match x {
    op_string @ Some(s) => {}, // error: use of moved value
    None => {},
}

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)) => {}, // error: cannot bind by-move and by-ref in the
                            //        same pattern
    None => panic!()
}

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)) => {},
    // or Some((y, z)) => {}
    None => panic!()
}

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!()
}

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:

#![feature(box_syntax)]

const CON : Box<i32> = box 0;

E0013

Static and const variables can refer to other const variables. But a const variable cannot refer to a static variable.

Erroneous code example:

static X: i32 = 42;
const Y: i32 = X;

In this example, Y cannot refer to X. 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;

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 }; // 'x' isn't a constant nor a function!

To avoid it, you have to replace the non-constant value:

const FOO: i32 = { const X : i32 = 0; X };
// or even:
const FOO2: i32 = { 0 }; // but brackets are useless here

E0015

A constant item was initialized with something that is not a constant expression.

Erroneous code example:

fn create_some() -> Option<u8> {
    Some(1)
}

const FOO: Option<u8> = create_some(); // error!

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> { // declared as a const function
    Some(1)
}

const FOO: Option<u8> = create_some(); // ok!

// These are also working:
struct Bar {
    x: u8,
}

const OTHER_FOO: Option<u8> = Some(1);
const BAR: Bar = Bar {x: 1};

E0023

A pattern attempted to extract an incorrect number of fields from a variant.

Erroneous code example:

enum Fruit {
    Apple(String, String),
    Pear(u32),
}

let x = Fruit::Apple(String::new(), String::new());

match x {
    Fruit::Apple(a) => {}, // error!
    _ => {}
}

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());

// Correct.
match x {
    Fruit::Apple(a, b) => {},
    _ => {}
}

Matching with the wrong number of fields has no sensible interpretation:

enum Fruit {
    Apple(String, String),
    Pear(u32),
}

let x = Fruit::Apple(String::new(), String::new());

// Incorrect.
match x {
    Fruit::Apple(a) => {},
    Fruit::Apple(a, b, c) => {},
}

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:

struct Foo {
    a: u8,
    b: u8,
}

fn main(){
    let x = Foo { a:1, b:2 };

    let Foo { a: x, a: y } = x;
    // error: field `a` bound multiple times in the pattern
}

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; // ok!
}

E0026

A struct pattern attempted to extract a non-existent field from a struct.

Erroneous code example:

struct Thing {
    x: u32,
    y: u32,
}

let thing = Thing { x: 0, y: 0 };

match thing {
    Thing { x, z } => {} // error: `Thing::z` field doesn't exist
}

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 } => {} // we renamed `y` to `z`
}

E0027

A pattern for a struct fails to specify a sub-pattern for every one of the struct’s fields.

Erroneous code example:

struct Dog {
    name: String,
    age: u32,
}

let d = Dog { name: "Rusty".to_string(), age: 8 };

// This is incorrect.
match d {
    Dog { age: x } => {}
}

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 } => {}
}

// This is also correct (ignore unused fields).
match d {
    Dog { age: x, .. } => {}
}

E0029

Something other than numbers and characters has been used for a range.

Erroneous code example:

let string = "salutations !";

// The ordering relation for strings cannot be evaluated at compile time,
// so this doesn't work:
match string {
    "hello" ..= "world" => {}
    _ => {}
}

// This is a more general version, using a guard:
match string {
    s if s >= "hello" && s <= "world" => {}
    _ => {}
}

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:

match 5u32 {
    // This range is ok, albeit pointless.
    1 ..= 1 => {}
    // This range is empty, and the compiler can tell.
    1000 ..= 5 => {}
}

E0033

A trait type has been dereferenced.

Erroneous code example:

let trait_obj: &SomeTrait = &"some_value";

// This tries to implicitly dereference to create an unsized local variable.
let &invalid = trait_obj;

// You can call methods without binding to the value being pointed at.
trait_obj.method_one();
trait_obj.method_two();

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:

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() // error, which foo() to call?
}

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() // and now that's good!
}

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()
}

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); // it displays "I am F"
    G::m(&f); // it displays "I am G"
}

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 {

}

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
    }
}

(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:

trait Trait {
    fn foo(&self) -> Self;
}

fn call_foo(x: Box<Trait>) {
    let y = x.foo(); // What type is y?
    // ...
}

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;
    // more functions
}

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) {
        // implementation 1
    }
}

impl Trait for u8 {
    fn foo(&self) {
        // implementation 2
    }
}
// ...

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) {
    // ...
}

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);
    // more methods
}

impl Trait for String {
    fn foo<T>(&self, on: T) {
        // implementation 1
    }
}

impl Trait for u8 {
    fn foo<T>(&self, on: T) {
        // implementation 2
    }
}

// 8 more implementations

Now, if we have the following code:

fn call_foo(thing: Box<Trait>) {
    thing.foo(true); // this could be any one of the 8 types above
    thing.foo(1);
    thing.foo("hello");
}

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;
    // more methods
}

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;
}

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;
}

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.

trait Foo {
    const X: i32;
}

impl Foo {}

A simple workaround is to use a helper method instead:

trait Foo {
    fn x(&self) -> i32;
}

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:

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>;
}

Here, the supertrait might have methods as follows:

trait Super<A: ?Sized> {
    fn get_a(&self) -> &A; // note that this is object safe!
}

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:

struct Foo {
    x: i32,
}

impl Drop for Foo {
    fn drop(&mut self) {
        println!("kaboom");
    }
}

fn main() {
    let mut x = Foo { x: -7 };
    x.drop(); // error: explicit use of destructor method
}

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); // ok!
}

E0044

You cannot use type or const parameters on foreign items.

Example of erroneous code:

extern "C" { fn some_func<T>(x: T); }

To fix this, replace the generic parameter with the specializations that you need:

extern "C" { fn some_func_i32(x: i32); }
extern "C" { fn some_func_i64(x: i64); }

E0045

Variadic parameters have been used on a non-C ABI function.

Erroneous code example:

#![feature(unboxed_closures)]

extern "rust-call" {
    fn foo(x: u8, ...); // error!
}

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, ...);
}

E0046

Items are missing in a trait implementation.

Erroneous code example:

trait Foo {
    fn foo();
}

struct Bar;

impl Foo for Bar {}
// error: not all trait items implemented, missing: `foo`

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() {} // ok!
}

E0049

An attempted implementation of a trait method has the wrong number of type or const parameters.

Erroneous code example:

trait Foo {
    fn foo<T: Default>(x: T) -> Self;
}

struct Bar;

// error: method `foo` has 0 type parameters but its trait declaration has 1
// type parameter
impl Foo for Bar {
    fn foo(x: bool) -> Self { Bar }
}

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 { // ok!
        Bar
    }
}

E0050

An attempted implementation of a trait method has the wrong number of function parameters.

Erroneous code example:

trait Foo {
    fn foo(&self, x: u8) -> bool;
}

struct Bar;

// error: method `foo` has 1 parameter but the declaration in trait `Foo::foo`
// has 2
impl Foo for Bar {
    fn foo(&self) -> bool { true }
}

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 { // ok!
        true
    }
}

E0053

The parameters of any trait method must match between a trait implementation and the trait definition.

Erroneous code example:

trait Foo {
    fn foo(x: u16);
    fn bar(&self);
}

struct Bar;

impl Foo for Bar {
    // error, expected u16, found i16
    fn foo(x: i16) { }

    // error, types differ in mutability
    fn bar(&mut self) { }
}

E0054

It is not allowed to cast to a bool.

Erroneous code example:

let x = 5;

// Not allowed, won't compile
let x_is_nonzero = x as bool;

If you are trying to cast a numeric type to a bool, you can compare it with zero instead:

let x = 5;

// Ok
let x_is_nonzero = x != 0;

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:

#![recursion_limit="4"]

struct Foo;

impl Foo {
    fn foo(&self) {}
}

fn main() {
    let foo = Foo;
    let ref_foo = &&&&&Foo;

    // error, reached the recursion limit while auto-dereferencing `&&&&&Foo`
    ref_foo.foo();
}

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:

let f = |x| x * 3;
let a = f();        // invalid, too few parameters
let b = f(4);       // this works!
let c = f(2, 3);    // invalid, too many parameters

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(); // this is valid, but f(3) would not work
}

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:

#![feature(unboxed_closures)]

fn foo<F: Fn<i32>>(f: F) -> F::Output { f(3) }

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) }

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:

use std::os::raw::{c_char, c_int};

extern "C" {
    fn printf(_: *const c_char, ...) -> c_int;
}

unsafe { printf(); } // error!

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\n").unwrap();
    printf(fmt.as_ptr());

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

    let fmt = CString::new("%d, %d\n").unwrap();
    printf(fmt.as_ptr(), 10, 5);
}

E0061

An invalid number of arguments was passed when calling a function.

Erroneous code example:

fn f(u: i32) {}

f(); // error!

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) {}

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:

struct Foo {
    x: i32,
}

fn main() {
    let x = Foo {
                x: 0,
                x: 0, // error: field `x` specified more than once
            };
}

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 }; // ok!
}

E0063

A struct’s or struct-like enum variant’s field was not provided.

Erroneous code example:

struct Foo {
    x: i32,
    y: i32,
}

fn main() {
    let x = Foo { x: 0 }; // error: missing field: `y`
}

Each field should be specified exactly once. Example:

struct Foo {
    x: i32,
    y: i32,
}

fn main() {
    let x = Foo { x: 0, y: 0 }; // ok!
}

E0067

An invalid left-hand side expression was used on an assignment operation.

Erroneous code example:

12 += 1; // error!

You need to have a place expression to be able to assign it something. For example:

let mut x: i8 = 12;
x += 1; // ok!

E0069

The compiler found a function whose body contains a return; statement but whose return type is not ().

Erroneous code example:

// error
fn foo() -> u8 {
    return;
}

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:

struct SomeStruct {
    x: i32,
    y: i32,
}

const SOME_CONST: i32 = 12;

fn some_other_func() {}

fn some_function() {
    SOME_CONST = 14; // error: a constant value cannot be changed!
    1 = 3; // error: 1 isn't a valid place!
    some_other_func() = 4; // error: we cannot assign value to a function!
    SomeStruct::x = 12; // error: SomeStruct a structure name but it is used
                        //        like a variable!
}

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; // that's good !

// ...

fn some_func(x: &mut i32) {
    *x = 12; // that's good !
}

E0071

A structure-literal syntax was used to create an item that is not a structure or enum variant.

Example of erroneous code:

type U32 = u32;
let t = U32 { value: 4 }; // error: expected struct, variant or union type,
                          // found builtin type `u32`

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;
}

E0072

A recursive type has infinite size because it doesn’t have an indirection.

Erroneous code example:

struct ListNode {
    head: u8,
    tail: Option<ListNode>, // error: no indirection here so impossible to
                            //        compute the type's size
}

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 ListNodes 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>>,
}

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> } // error

One fix is to use Option, like so:

struct Foo { x: Option<Box<Foo>> }

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, T);

This will not:

#![feature(repr_simd)]

#[repr(simd)]
struct Good(u32, u32, u32, u32);

E0075

A #[simd] attribute was applied to an empty tuple struct.

Erroneous code example:

#![feature(repr_simd)]

#[repr(simd)]
struct Bad; // error!

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); // ok!

E0076

All types in a tuple struct aren’t the same when using the #[simd] attribute.

Erroneous code example:

#![feature(repr_simd)]

#[repr(simd)]
struct Bad(u16, u32, u32 u32); // error!

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, u32); // ok!

E0077

A tuple struct’s element isn’t a machine type when using the #[simd] attribute.

Erroneous code example:

#![feature(repr_simd)]

#[repr(simd)]
struct Bad(String); // error!

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, u32); // ok!

E0080

A constant value failed to get evaluated.

Erroneous code example:

enum Enum {
    X = (1 << 500),
    Y = (1 / 0),
}

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:

enum Enum {
    P = 3,
    X = 3, // error!
    Y = 5,
}

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, // ok!
    Y = 5,
}

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.

enum Bad {
    X,
    Y = 0, // error!
}

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:

#[repr(i32)]
enum NightsWatch {} // error: unsupported representation for zero-variant enum

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,
}

or you remove the integer representation of your enum:

enum NightsWatch {}

E0087

Note: this error code is no longer emitted by the compiler.

Too many type arguments were supplied for a function. For example:

fn foo<T>() {}

fn main() {
    foo::<f64, bool>(); // error: wrong number of type arguments:
                        //        expected 1, found 2
}

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:

fn f() {}

fn main() {
    f::<'static>() // error: wrong number of lifetime arguments:
                   //        expected 0, found 1
}

Please check you give the right number of lifetime arguments. Example:

fn f() {}

fn main() {
    f() // ok!
}

It’s also important to note that the Rust compiler can generally determine the lifetime by itself. Example:

struct Foo {
    value: String
}

impl Foo {
    // it can be written like this
    fn get_value<'a>(&'a self) -> &'a str { &self.value }
    // but the compiler works fine with this too:
    fn without_lifetime(&self) -> &str { &self.value }
}

fn main() {
    let f = Foo { value: "hello".to_owned() };

    println!("{}", f.get_value());
    println!("{}", f.without_lifetime());
}

E0089

Note: this error code is no longer emitted by the compiler.

Too few type arguments were supplied for a function. For example:

fn foo<T, U>() {}

fn main() {
    foo::<f64>(); // error: wrong number of type arguments: expected 2, found 1
}

Note that if a function takes multiple type arguments but you want the compiler to infer some of them, you can use type placeholders:

fn foo<T, U>(x: T) {}

fn main() {
    let x: bool = true;
    foo::<f64>(x);    // error: wrong number of type arguments:
                      //        expected 2, found 1
    foo::<_, f64>(x); // same as `foo::<bool, f64>(x)`
}

E0090

Note: this error code is no longer emitted by the compiler.

You gave too few lifetime arguments. Example:

fn foo<'a: 'b, 'b: 'a>() {}

fn main() {
    foo::<'static>(); // error: wrong number of lifetime arguments:
                      //        expected 2, found 1
}

Please check you give the right number of lifetime arguments. Example:

fn foo<'a: 'b, 'b: 'a>() {}

fn main() {
    foo::<'static, 'static>();
}

E0091

An unnecessary type or const parameter was given in a type alias.

Erroneous code example:

type Foo<T> = u32; // error: type parameter `T` is unused
// or:
type Foo<A,B> = Box<A>; // error: type parameter `B` is unused

Please check you didn’t write too many parameters. Example:

type Foo = u32; // ok!
type Foo2<A> = Box<A>; // ok!

E0092

An undefined atomic operation function was declared.

Erroneous code example:

#![feature(intrinsics)]

extern "rust-intrinsic" {
    fn atomic_foo(); // error: unrecognized atomic operation
                     //        function
}

Please check you didn’t make a mistake in the function’s name. All intrinsic functions are defined in compiler/rustc_codegen_llvm/src/intrinsic.rs and in library/core/src/intrinsics.rs in the Rust source code. Example:

#![feature(intrinsics)]

extern "rust-intrinsic" {
    fn atomic_fence(); // ok!
}

E0093

An unknown intrinsic function was declared.

Erroneous code example:

#![feature(intrinsics)]

extern "rust-intrinsic" {
    fn foo(); // error: unrecognized intrinsic function: `foo`
}

fn main() {
    unsafe {
        foo();
    }
}

Please check you didn’t make a mistake in the function’s name. All intrinsic functions are defined in compiler/rustc_codegen_llvm/src/intrinsic.rs and in library/core/src/intrinsics.rs in the Rust source code. Example:

#![feature(intrinsics)]

extern "rust-intrinsic" {
    fn atomic_fence(); // ok!
}

fn main() {
    unsafe {
        atomic_fence();
    }
}

E0094

An invalid number of type parameters was given to an intrinsic function.

Erroneous code example:

#![feature(intrinsics)]

extern "rust-intrinsic" {
    fn size_of<T, U>() -> usize; // error: intrinsic has wrong number
                                 //        of type parameters
}

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; // ok!
}

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:

struct Foo1 { x: &bool }
              // ^ expected lifetime parameter
struct Foo2<'a> { x: &'a bool } // correct

struct Bar1 { x: Foo2 }
              // ^^^^ expected lifetime parameter
struct Bar2<'a> { x: Foo2<'a> } // correct

enum Baz1 { A(u8), B(&bool), }
                  // ^ expected lifetime parameter
enum Baz2<'a> { A(u8), B(&'a bool), } // correct

type MyStr1 = &str;
           // ^ expected lifetime parameter
type MyStr2<'a> = &'a str; // correct

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:

// error, no input lifetimes
fn foo() -> &str { }

// error, `x` and `y` have distinct lifetimes inferred
fn bar(x: &str, y: &str) -> &str { }

// error, `y`'s lifetime is inferred to be distinct from `x`'s
fn baz<'a>(x: &'a str, y: &str) -> &str { }

E0107

An incorrect number of generic arguments was provided.

Erroneous code example:

struct Foo<T> { x: T }

struct Bar { x: Foo }             // error: wrong number of type arguments:
                                  //        expected 1, found 0
struct Baz<S, T> { x: Foo<S, T> } // error: wrong number of type arguments:
                                  //        expected 1, found 2

fn foo<T, U>(x: T, y: U) {}
fn f() {}

fn main() {
    let x: bool = true;
    foo::<bool>(x);                 // error: wrong number of type arguments:
                                    //        expected 2, found 1
    foo::<bool, i32, i32>(x, 2, 4); // error: wrong number of type arguments:
                                    //        expected 2, found 3
    f::<'static>();                 // error: wrong number of lifetime arguments
                                    //        expected 0, found 1
}

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> }               // ok!
struct Baz<S, T> { x: Foo<S>, y: Foo<T> } // ok!

fn foo<T, U>(x: T, y: U) {}
fn f() {}

fn main() {
    let x: bool = true;
    foo::<bool, u32>(x, 12);              // ok!
    f();                                  // ok!
}

E0109

You tried to provide a generic argument to a type which doesn’t need it.

Erroneous code example:

type X = u32<i32>; // error: type arguments are not allowed for this type
type Y = bool<'static>; // error: lifetime parameters are not allowed on
                        //        this type

Check that you used the correct argument and that the definition is correct.

Example:

type X = u32; // ok!
type Y = bool; // ok!

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:

impl Vec<u8> { } // error

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 either:

• 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:

type Bytes = Vec<u8>;

impl Bytes { } // error, same as above

E0117

Only traits defined in the current crate can be implemented for arbitrary types.

Erroneous code example:

impl Drop for u32 {}

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; // you define your type in your crate

impl Drop for Foo { // and you can implement the trait on it!
    // code of trait implementation here
}

impl From<Foo> for i32 { // or you use a type from your crate as
                         // a type parameter
    fn from(i: Foo) -> i32 {
        0
    }
}

Alternatively, define a trait locally and implement that instead:

trait Bar {
    fn get(&self) -> usize;
}

impl Bar for u32 {
    fn get(&self) -> usize { 0 }
}

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, enum, union, or trait object.

Erroneous code example:

impl (u8, u8) { // error: no nominal type found for inherent implementation
    fn get_state(&self) -> String {
        // ...
    }
}

To fix this error, please implement a trait on the type or wrap it in a struct. Example:

// we create a trait here
trait LiveLongAndProsper {
    fn get_state(&self) -> String;
}

// and now you can implement it on (u8, u8)
impl LiveLongAndProsper for (u8, u8) {
    fn get_state(&self) -> String {
        "He's dead, Jim!".to_owned()
    }
}

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()
    }
}

Instead of defining an inherent implementation on a reference, you could also move the reference inside the implementation:

struct Foo;

impl &Foo { // error: no nominal type found for inherent implementation
    fn bar(self, other: Self) {}
}

becomes

struct Foo;

impl Foo {
    fn bar(&self, other: &Self) {}
}

E0119

There are conflicting trait implementations for the same type.

Erroneous code example:

trait MyTrait {
    fn get(&self) -> usize;
}

impl<T> MyTrait for T {
    fn get(&self) -> usize { 0 }
}

struct Foo {
    value: usize
}

impl MyTrait for Foo { // error: conflicting implementations of trait
                       //        `MyTrait` for type `Foo`
    fn get(&self) -> usize { self.value }
}

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 }
}

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(); // the trait is implemented so we can use it
}

E0120

Drop was implemented on a trait, which is not allowed: only structs and enums can implement Drop.

Erroneous code example:

trait MyTrait {}

impl Drop for MyTrait {
    fn drop(&mut self) {}
}

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) {}
}

Alternatively, wrapping trait objects requires something:

trait MyTrait {}

//or Box<MyTrait>, if you wanted an owned trait object
struct MyWrapper<'a> { foo: &'a MyTrait }

impl <'a> Drop for MyWrapper<'a> {
    fn drop(&mut self) {}
}

E0121

The type placeholder _ was used within a type on an item’s signature.

Erroneous code example:

fn foo() -> _ { 5 } // error

static BAR: _ = "test"; // error

In those cases, you need to provide the type explicitly:

fn foo() -> i32 { 5 } // ok!

static BAR: &str = "test"; // ok!

The type placeholder _ can be used outside item’s signature as follows:

let x = "a4a".split('4')
    .collect::<Vec<_>>(); // No need to precise the Vec's generic type.

E0124

A struct was declared with two fields having the same name.

Erroneous code example:

struct Foo {
    field1: i32,
    field1: i32, // error: field is already declared
}

Please verify that the field names have been correctly spelled. Example:

struct Foo {
    field1: i32,
    field2: i32, // ok!
}

E0128

A type parameter with default value is using forward declared identifier.

Erroneous code example:

struct Foo<T = U, U = ()> {
    field1: T,
    field2: U,
}
// error: type parameters with a default cannot use forward declared
//        identifiers

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,
}

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:

extern "C" {
    fn foo((a, b): (u32, u32)); // error: patterns aren't allowed in foreign
                                //        function declarations
}

To fix this error, replace the pattern argument with a regular one. Example:

struct SomeStruct {
    a: u32,
    b: u32,
}

extern "C" {
    fn foo(s: SomeStruct); // ok!
}

Or:

extern "C" {
    fn foo(a: (u32, u32)); // ok!
}

E0131

The main function was defined with generic parameters.

Erroneous code example:

fn main<T>() { // error: main function is not allowed to have generic parameters
}

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:

#![feature(start)]

#[start]
fn f<T>() {}

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;

Example:

#![feature(start)]

#[start]
fn my_start(argc: isize, argv: *const *const u8) -> isize {
    0
}

E0133

Unsafe code was used outside of an unsafe function or block.

Erroneous code example:

unsafe fn f() { return; } // This is the unsafe code

fn main() {
    f(); // error: call to unsafe function requires unsafe function or block
}

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(); } // ok!
}

See the unsafe section of the Book for more details.

E0136

More than one main function was found.

Erroneous code example:

fn main() {
    // ...
}

// ...

fn main() { // error!
    // ...
}

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:

#![feature(main)]

#[main]
fn foo() {}

#[main]
fn f() {} // error: multiple functions with a `#[main]` attribute

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() {} // ok!

E0138

More than one function was declared with the #[start] attribute.

Erroneous code example:

#![feature(start)]

#[start]
fn foo(argc: isize, argv: *const *const u8) -> isize {}

#[start]
fn f(argc: isize, argv: *const *const u8) -> isize {}
// error: multiple 'start' functions

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 } // ok!

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>) {
    // we are transmuting between Vec<T> and Foo<F> here
    let y: Foo<T> = unsafe { transmute(x) };
    // do something with y
}

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) }
    }
}

// ... more impls for the types you intend to transmute

fn foo<T: MyTransmutableType>(x: Vec<T>) {
    let y: Foo<T> = <T as MyTransmutableType>::transmute(x);
    // do something with y
}

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) // `v` transmuted to `SomeType`
}

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:

#![feature(lang_items)]

#[lang = "owned_box"]
struct Foo; // error: duplicate lang item found: `owned_box`

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:

#![no_std]

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() {
    // Variable declaration before import
    let x = 0;
    use std::io::Read;
    // ...
}

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;
    // ...
}

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:

enum EFoo { A, B, C, D }

trait Foo {
    const X: EFoo;
}

fn test<A: Foo>(arg: EFoo) {
    match arg {
        A::X => { // error!
            println!("A::X");
        }
    }
}

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 => {}
    _ => {}
}

E0161

A value was moved whose size was not known at compile time.

Erroneous code example:

#![feature(box_syntax)]

fn main() {
    let array: &[isize] = &[1, 2, 3];
    let _x: Box<[isize]> = box *array;
    // error: cannot move a value of type [isize]: the size of [isize] cannot
    //        be statically determined
}

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; // ok!
}

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);

// This fails to compile because the match is irrefutable.
if let Irrefutable(x) = irr {
    // This body will always be executed.
    // ...
}

Try this instead:

struct Irrefutable(i32);
let irr = Irrefutable(0);

let Irrefutable(x) = irr;
println!("{}", x);

E0164

Something which is neither a tuple struct nor a tuple variant was used as a pattern.

Erroneous code example:

enum A {
    B,
    C,
}

impl A {
    fn new() {}
}

fn bar(foo: A) {
    match foo {
        A::new() => (), // error!
        _ => {}
    }
}

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 => (), // ok!
        _ => {}
    }
}

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);

// This fails to compile because the match is irrefutable.
while let Irrefutable(x) = irr {
    // ...
}

Try this instead:

struct Irrefutable(i32);
let irr = Irrefutable(0);

loop {
    let Irrefutable(x) = irr;
    // ...
}

E0170

A pattern binding is using the same name as one of the variants of a type.

Erroneous code example:

enum Method {
    GET,
    POST,
}

fn is_empty(s: Method) -> bool {
    match s {
        GET => true,
        _ => false
    }
}

fn main() {}

Enum variants are qualified by default. For example, given this type:

enum Method {
    GET,
    POST,
}

You would match it using:

enum Method {
    GET,
    POST,
}

let m = Method::GET;

match m {
    Method::GET => {},
    Method::POST => {},
}

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 }

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 }

E0178

The + type operator was used in an ambiguous context.

Erroneous code example:

trait Foo {}

struct Bar<'a> {
    x: &'a Foo + 'a,     // error!
    y: &'a mut Foo + 'a, // error!
    z: fn() -> Foo + 'a, // error!
}

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),     // ok!
    y: &'a mut (Foo + 'a), // ok!
    z: fn() -> (Foo + 'a), // ok!
}

More details can be found in RFC 438.

E0184

The Copy trait was implemented on a type with a Drop implementation.

Erroneous code example:

#[derive(Copy)]
struct Foo; // error!

impl Drop for Foo {
    fn drop(&mut self) {
    }
}

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:

trait Foo {
    fn foo();
}

struct Bar;

impl Foo for Bar {
    // error, method `foo` has a `&self` declaration in the impl, but not in
    // the trait
    fn foo(&self) {}
}

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() {} // ok!
}

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:

trait Foo {
    fn foo(&self);
}

struct Bar;

impl Foo for Bar {
    // error, method `foo` has a `&self` declaration in the trait, but not in
    // the impl
    fn foo() {}
}

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) {} // ok!
}

E0191

An associated type wasn’t specified for a trait object.

Erroneous code example:

trait Trait {
    type Bar;
}

type Foo = Trait; // error: the value of the associated type `Bar` (from
                  //        the trait `Trait`) must be specified

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>; // ok!

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) { }
}

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) { }
}

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:

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) {
    // error: lifetime parameters or bounds on method `bar`
    // do not match the trait declaration
    }
}

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) { // ok!
    }
}

E0197

An inherent implementation was marked unsafe.

Erroneous code example:

struct Foo;

unsafe impl Foo { } // error!

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 { } // ok!

E0198

A negative implementation was marked as unsafe.

Erroneous code example:

struct Foo;

unsafe impl !Clone for Foo { } // error!

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:

#![feature(auto_traits)]

struct Foo;

auto trait Enterprise {}

impl !Enterprise for Foo { }

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:

struct Foo;

trait Bar { }

unsafe impl Bar for Foo { } // error!

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 { } // ok!

E0200

An unsafe trait was implemented without an unsafe implementation.

Erroneous code example:

struct Foo;

unsafe trait Bar { }

impl Bar for Foo { } // error!

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 { } // ok!

E0201

Two associated items (like methods, associated types, associated functions, etc.) were defined with the same identifier.

Erroneous code example:

struct Foo(u8);

impl Foo {
    fn bar(&self) -> bool { self.0 > 5 }
    fn bar() {} // error: duplicate associated function
}

trait Baz {
    type Quux;
    fn baz(&self) -> bool;
}

impl Baz for Foo {
    type Quux = u32;

    fn baz(&self) -> bool { true }

    // error: duplicate method
    fn baz(&self) -> bool { self.0 > 5 }

    // error: duplicate associated type
    type Quux = u32;
}

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 }
}

E0203

Having multiple relaxed default bounds is unsupported.

Erroneous code example:

struct Bad<T: ?Sized + ?Send>{
    inner: T
}

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
}

E0204

The Copy trait was implemented on a type which contains a field that doesn’t implement the Copy trait.

Erroneous code example:

struct Foo {
    foo: Vec<u32>,
}

impl Copy for Foo { } // error!

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:

#[derive(Copy)] // error!
struct Foo<'a> {
    ty: &'a mut bool,
}

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

enum Foo {
    Bar(Vec<u32>),
    Baz,
}

impl Copy for Foo { }

This fails because Vec<T> does not implement Copy for any T.

Here’s another example that will fail:

#[derive(Copy)]
enum Foo<'a> {
    Bar(&'a mut bool),
    Baz,
}

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:

type Foo = [u8; 256];
impl Copy for Foo { } // error!

#[derive(Copy, Clone)]
struct Bar;

impl Copy for &'static mut Bar { } // error!

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:

struct Foo;

impl<T: Default> Foo {
    // error: the type parameter `T` is not constrained by the impl trait, self
    // type, or predicates [E0207]
    fn get(&self) -> T {
        <T as Default>::default()
    }
}

Any type 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;

// Move the type parameter from the impl to the method
impl Foo {
    fn get<T: Default>(&self) -> T {
        <T as Default>::default()
    }
}

Error example 2

As another example, suppose we have a Maker trait and want to establish a type FooMaker that makes Foos:

trait Maker {
    type Item;
    fn make(&mut self) -> Self::Item;
}

struct Foo<T> {
    foo: T
}

struct FooMaker;

impl<T: Default> Maker for FooMaker {
// error: the type parameter `T` is not constrained by the impl trait, self
// type, or predicates [E0207]
    type Item = Foo<T>;

    fn make(&mut self) -> Foo<T> {
        Foo { foo: <T as Default>::default() }
    }
}

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
}

// Add a type parameter to `FooMaker`
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(),
        }
    }
}

Another way is to do away with the associated type in Maker and use an input type parameter instead:

// Use a type parameter instead of an associated type here
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() }
    }
}

Additional information

For more information, please see RFC 447.

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:

extern crate foo;
use foo::ForeignTrait;

impl<T> ForeignTrait for T { } // error

To work around this, it can be covered with a local type, MyType:

struct MyType<T>(T);
impl<T> ForeignTrait for MyType<T> { } // Ok

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:

struct MyType2;
impl<T> ForeignTrait2<T, MyType<T>> for MyType2 { } // error

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:

impl<T> ForeignTrait2<MyType<T>, T> for MyType2 { } // Ok

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:

impl<P1, ..., Pm> ForeignTrait<T1, ..., Tn> for T0 { ... }

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:

1. At least one of the types T0..=Tn must be a local type. Let Ti be the first such type.
2. 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:

#![feature(intrinsics)]

extern "rust-intrinsic" {
    fn size_of<T>(); // error: intrinsic has wrong type
}

// or:

fn main() -> i32 { 0 }
// error: main function expects type: `fn() {main}`: expected (), found i32

// or:

let x = 1u8;
match x {
    0u8..=3i8 => (),
    // error: mismatched types in range: expected u8, found i8
    _ => ()
}

// or:

use std::rc::Rc;
struct Foo;

impl Foo {
    fn x(self: Rc<Foo>) {}
    // error: mismatched self type: expected `Foo`: expected struct
    //        `Foo`, found struct `alloc::rc::Rc`
}

For the first code example, please check the function definition. Example:

#![feature(intrinsics)]

extern "rust-intrinsic" {
    fn size_of<T>() -> usize; // ok!
}

The second case example is a bit particular: the main function must always have this definition:

fn main();

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 => (), // ok!
    _ => ()
}

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>) {} // ok!
}

E0212

Cannot use the associated type of a trait with uninferred generic parameters.

Erroneous code example:

pub trait Foo<T> {
    type A;

    fn get(&self, t: T) -> Self::A;
}

fn foo2<I : for<'x> Foo<&'x isize>>(
    field: I::A) {} // error!

In this example, we have to instantiate 'x, and we don’t know what lifetime to instantiate it with. To fix this, spell out the precise lifetimes involved. Example:

pub trait Foo<T> {
    type A;

    fn get(&self, t: T) -> Self::A;
}

fn foo3<I : for<'x> Foo<&'x isize>>(
    x: <I as Foo<&isize>>::A) {} // ok!


fn foo4<'a, I : for<'x> Foo<&'x isize>>(
    x: <I as Foo<&'a isize>>::A) {} // ok!

E0214

A generic type was described using parentheses rather than angle brackets.

Erroneous code example:

let v: Vec(&str) = vec!["foo"];

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"];

E0220

The associated type used was not defined in the trait.

Erroneous code example:

trait T1 {
    type Bar;
}

type Foo = T1<F=i32>; // error: associated type `F` not found for `T1`

// or:

trait T2 {
    type Bar;

    // error: Baz is used but not declared
    fn return_bool(&self, _: &Self::Bar, _: &Self::Baz) -> bool;
}

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>; // ok!

// or:

trait T2 {
    type Bar;
    type Baz; // we declare `Baz` in our trait.

    // and now we can use it here:
    fn return_bool(&self, _: &Self::Bar, _: &Self::Baz) -> bool;
}

E0221

An attempt was made to retrieve an associated type, but the type was ambiguous.

Erroneous code example:

trait T1 {}
trait T2 {}

trait Foo {
    type A: T1;
}

trait Bar : Foo {
    type A: T2;
    fn do_something() {
        let _: Self::A;
    }
}

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;
    }
}

E0222

An attempt was made to constrain an associated type.

Erroneous code example:

pub trait Vehicle {
    type Color;
}

pub trait Box {
    type Color;
}

pub trait BoxCar : Box + Vehicle {}

fn dent_object<COLOR>(c: dyn BoxCar<Color=COLOR>) {} // Invalid constraint

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 {}

// Introduce a new `CAR` type parameter
fn foo<CAR, COLOR>(
    c: CAR,
) where
    // Bind the type parameter `CAR` to the trait `BoxCar`
    CAR: BoxCar,
    // Further restrict `<BoxCar as Vehicle>::Color` to be the same as the
    // type parameter `COLOR`
    CAR: Vehicle<Color = COLOR>,
    // We can also simultaneously restrict the other trait's associated type
    CAR: Box<Color = COLOR>
{}

E0223

An attempt was made to retrieve an associated type, but the type was ambiguous.

Erroneous code example:

trait MyTrait {type X; }

fn main() {
    let foo: MyTrait::X;
}

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;
}

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 declared with no traits.

Erroneous code example:

type Foo = dyn 'static +;

Rust does not currently support this.

To solve, ensure that the trait object has at least one trait:

type Foo = dyn 'static + Copy;

E0225

Multiple types were used as bounds for a closure or trait object.

Erroneous code example:

fn main() {
    let _: Box<dyn std::io::Read + std::io::Write>;
}

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>;
}

E0226

More than one explicit lifetime bound was used on a trait object.

Example of erroneous code:

trait Foo {}

type T<'a, 'b> = dyn Foo + 'a + 'b; // error: Trait object `arg` has two
                                    //        lifetime bound, 'a and 'b.

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;

E0228

The lifetime bound for this object type cannot be deduced from context and must be specified.

Erroneous code example:

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>;

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>;

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:

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) {}
// error: associated type bindings are not allowed here

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) {} // ok!

Or in the where clause:

fn baz<I>(x: &<I as Foo>::A) where I: Foo<A=Bar> {}

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:

#![feature(rustc_attrs)]

#[rustc_on_unimplemented = "error on `{Self}` with params `<{A},{B}>`"] // error
trait BadAnnotation<A> {}

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:

#![feature(rustc_attrs)]

#[rustc_on_unimplemented = "error on `{Self}` with params `<{A},{}>`"] // error!
trait BadAnnotation<A> {}

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:

#![feature(rustc_attrs)]

#[rustc_on_unimplemented(lorem="")] // error!
trait BadAnnotation {}

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:

struct Foo<T> { x: T }

struct Bar { x: Foo }

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:

struct Foo { x: bool }

struct Bar<S, T> { x: Foo<S, T> }

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::*; // error, do `use foo::baz as quux` instead on the previous line

fn main() {}

mod foo {
    pub struct baz;
}

mod bar {
    pub mod baz {}
}

E0252

Two items of the same name cannot be imported without rebinding one of the items under a new local name.

Erroneous code example:

use foo::baz;
use bar::baz; // error, do `use bar::baz as quux` instead

fn main() {}

mod foo {
    pub struct baz;
}

mod bar {
    pub mod baz {}
}

You can use aliases in order to fix this error. Example:

use foo::baz as foo_baz;
use bar::baz; // ok!

fn main() {}

mod foo {
    pub struct baz;
}

mod bar {
    pub mod baz {}
}

Or you can reference the item with its parent:

use bar::baz;

fn main() {
    let x = foo::baz; // ok!
}

mod foo {
    pub struct baz;
}

mod bar {
    pub mod baz {}
}

E0253

Attempt was made to import an unimportable value. This can happen when trying to import a method from a trait.

Erroneous code example:

mod foo {
    pub trait MyTrait {
        fn do_something();
    }
}

use foo::MyTrait::do_something;
// error: `do_something` is not directly importable

fn main() {}

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:

extern crate core;

mod foo {
    pub trait core {
        fn do_something();
    }
}

use foo::core;  // error: an extern crate named `core` has already
                //        been imported in this module

fn main() {}

To fix this issue, you have to rename at least one of the two imports. Example:

extern crate core as libcore; // ok!

mod foo {
    pub trait core {
        fn do_something();
    }
}

use foo::core;

fn main() {}

E0255

You can’t import a value whose name is the same as another value defined in the module.

Erroneous code example:

use bar::foo; // error: an item named `foo` is already in scope

fn foo() {}

mod bar {
     pub fn foo() {}
}

fn main() {}

You can use aliases in order to fix this error. Example:

use bar::foo as bar_foo; // ok!

fn foo() {}

mod bar {
     pub fn foo() {}
}

fn main() {}

Or you can reference the item with its parent:

fn foo() {}

mod bar {
     pub fn foo() {}
}

fn main() {
    bar::foo(); // we get the item by referring to its parent
}

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:

use foo::Bar; // error

type Bar = u32;

mod foo {
    pub mod Bar { }
}

fn main() {}

E0259

The name chosen for an external crate conflicts with another external crate that has been imported into the current module.

Erroneous code example:

extern crate core;
extern crate std as core;

fn main() {}

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() {}

E0260

The name for an item declaration conflicts with an external crate’s name.

Erroneous code example:

extern crate core;

struct core;

fn main() {}

There are two possible solutions:

Solution #1: Rename the item.

extern crate core;

struct xyz;

Solution #2: Import the crate with a different name.

extern crate core as xyz;

struct abc;

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:

// error, use of undeclared lifetime name `'a`
fn foo(x: &'a str) { }

struct Foo {
    // error, use of undeclared lifetime name `'a`
    x: &'a str,
}

These can be fixed by declaring lifetime parameters:

struct Foo<'a> {
    x: &'a str,
}

fn foo<'a>(x: &'a str) {}

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:

struct Foo<'a> {
    x: &'a str,
}

// error,  use of undeclared lifetime name `'a`
impl Foo<'a> {
    fn foo<'a>(x: &'a str) {}
}

This is fixed by declaring the impl block like this:

struct Foo<'a> {
    x: &'a str,
}

// correct
impl<'a> Foo<'a> {
    fn foo(x: &'a str) {}
}

E0262

An invalid name was used for a lifetime parameter.

Erroneous code example:

// error, invalid lifetime parameter name `'static`
fn foo<'static>(x: &'static str) { }

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:

fn foo<'a, 'b, 'a>(x: &'a str, y: &'b str, z: &'a str) { // error!
}

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) { // ok!
}

E0264

An unknown external lang item was used.

Erroneous code example:

#![feature(lang_items)]

extern "C" {
    #[lang = "cake"] // error: unknown external lang item: `cake`
    fn cake();
}

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"] // ok!
    fn cake();
}

E0267

A loop keyword (break or continue) was used inside a closure but outside of any loop.

Erroneous code example:

let w = || { break; }; // error: `break` inside of a closure

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();

E0268

A loop keyword (break or continue) was used outside of a loop.

Erroneous code example:

fn some_func() {
    break; // error: `break` outside of a loop
}

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: