Rust Compiler Error Index

match Some(0) {
    Some(bar) => {/* ... */}
    x => {/* ... */} // This handles the `None` case
    _ => {/* ... */} // All possible cases have already been handled
}Run

enum Empty {}

fn foo(x: Empty) {
    match x {
        // empty
    }
}Run

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

const NAN: f32 = 0.0 / 0.0;

let number = 0.1f32;

match number {
    NAN => { /* ... */ },
    _ => {}
}Run

let number = 0.1f32;

match number {
    x if x.is_nan() => { /* ... */ }
    _ => {}
}Run

E0004

This error indicates that the compiler cannot guarantee a matching pattern for one or more possible inputs to a match expression. Guaranteed matches are required in order to assign values to match expressions, or alternatively, determine the flow of execution. Erroneous code example:

enum Terminator {
    HastaLaVistaBaby,
    TalkToMyHand,
}

let x = Terminator::HastaLaVistaBaby;

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

If you encounter this error you must alter your patterns so that every possible value of the input type is matched. For types with a small number of variants (like enums) you should probably cover all cases explicitly. Alternatively, the underscore _ wildcard pattern can be added after all other patterns to match "anything else". Example:

enum Terminator {
    HastaLaVistaBaby,
    TalkToMyHand,
}

let x = Terminator::HastaLaVistaBaby;

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

// or:

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

E0005

Patterns used to bind names must be irrefutable, that is, they must guarantee that a name will be extracted in all cases. Erroneous code example:

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

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

E0007

This error indicates that the bindings in a match arm would require a value to be moved into more than one location, thus violating unique ownership. Code like the following is invalid as it requires the entire Option<String> to be moved into a variable called op_string while simultaneously requiring the inner String to be moved into a variable called s.

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

match x {
    op_string @ Some(s) => {}, // error: cannot bind by-move with sub-bindings
    None => {},
}Run

See also the error E0303.

E0008

Names bound in match arms retain their type in pattern guards. As such, if a name is bound by move in a pattern, it should also be moved to wherever it is referenced in the pattern guard code. Doing so however would prevent the name from being available in the body of the match arm. Consider the following:

match Some("hi".to_string()) {
    Some(s) if s.len() == 0 => {}, // use s.
    _ => {},
}Run

The variable s has type String, and its use in the guard is as a variable of type String. The guard code effectively executes in a separate scope to the body of the arm, so the value would be moved into this anonymous scope and therefore becomes unavailable in the body of the arm.

The problem above can be solved by using the ref keyword.

match Some("hi".to_string()) {
    Some(ref s) if s.len() == 0 => {},
    _ => {},
}Run

Though this example seems innocuous and easy to solve, the problem becomes clear when it encounters functions which consume the value:

struct A{}

impl A {
    fn consume(self) -> usize {
        0
    }
}

fn main() {
    let a = Some(A{});
    match a {
        Some(y) if y.consume() > 0 => {}
        _ => {}
    }
}Run

In this situation, even the ref keyword cannot solve it, since borrowed content cannot be moved. This problem cannot be solved generally. If the value can be cloned, here is a not-so-specific solution:

#[derive(Clone)]
struct A{}

impl A {
    fn consume(self) -> usize {
        0
    }
}

fn main() {
    let a = Some(A{});
    match a{
        Some(ref y) if y.clone().consume() > 0 => {}
        _ => {}
    }
}Run

If the value will be consumed in the pattern guard, using its clone will not move its ownership, so the code works.

E0009

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:

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

You have two solutions:

Solution #1: Bind the pattern's values the same way.

struct X { x: (), }

let x = Some((X { x: () }, X { x: () }));
match x {
    Some((ref y, ref z)) => {},
    // or Some((y, z)) => {}
    None => panic!()
}Run

Solution #2: Implement the Copy trait for the X structure.

However, please keep in mind that the first solution should be preferred.

#[derive(Clone, Copy)]
struct X { x: (), }

let x = Some((X { x: () }, X { x: () }));
match x {
    Some((y, ref z)) => {},
    None => panic!()
}Run

E0010

The value of statics and constants must be known at compile time, and they live for the entire lifetime of a program. Creating a boxed value allocates memory on the heap at runtime, and therefore cannot be done at compile time. Erroneous code example:

#![feature(box_syntax)]

const CON : Box<i32> = box 0;Run

E0013

Static and const variables can refer to other const variables. But a const variable cannot refer to a static variable. For example, Y cannot refer to X here:

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

To fix this, the value can be extracted as a const and then used:

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

E0015

The only functions that can be called in static or constant expressions are const functions, and struct/enum constructors. const functions are only available on a nightly compiler. Rust currently does not support more general compile-time function execution.

const FOO: Option<u8> = Some(1); // enum constructor
struct Bar {x: u8}
const BAR: Bar = Bar {x: 1}; // struct constructorRun

See RFC 911 for more details on the design of const fns.

E0016

Blocks in constants may only contain items (such as constant, function definition, etc...) and a tail expression. Erroneous code example:

const FOO: i32 = { let x = 0; x }; // 'x' isn't an item!Run

To avoid it, you have to replace the non-item object:

const FOO: i32 = { const X : i32 = 0; X };Run

E0017

References in statics and constants may only refer to immutable values. Erroneous code example:

static X: i32 = 1;
const C: i32 = 2;

// these three are not allowed:
const CR: &'static mut i32 = &mut C;
static STATIC_REF: &'static mut i32 = &mut X;
static CONST_REF: &'static mut i32 = &mut C;Run

Statics are shared everywhere, and if they refer to mutable data one might violate memory safety since holding multiple mutable references to shared data is not allowed.

If you really want global mutable state, try using static mut or a global UnsafeCell.

E0018

The value of static and constant integers must be known at compile time. You can't cast a pointer to an integer because the address of a pointer can vary.

For example, if you write:

static MY_STATIC: u32 = 42;
static MY_STATIC_ADDR: usize = &MY_STATIC as *const _ as usize;
static WHAT: usize = (MY_STATIC_ADDR^17) + MY_STATIC_ADDR;Run

Then MY_STATIC_ADDR would contain the address of MY_STATIC. However, the address can change when the program is linked, as well as change between different executions due to ASLR, and many linkers would not be able to calculate the value of WHAT.

On the other hand, static and constant pointers can point either to a known numeric address or to the address of a symbol.

static MY_STATIC: u32 = 42;
static MY_STATIC_ADDR: &'static u32 = &MY_STATIC;
const CONST_ADDR: *const u8 = 0x5f3759df as *const u8;Run

This does not pose a problem by itself because they can't be accessed directly.

E0019

A function call isn't allowed in the const's initialization expression because the expression's value must be known at compile-time. Erroneous code example:

enum Test {
    V1
}

impl Test {
    fn test(&self) -> i32 {
        12
    }
}

fn main() {
    const FOO: Test = Test::V1;

    const A: i32 = FOO.test(); // You can't call Test::func() here!
}Run

Remember: you can't use a function call inside a const's initialization expression! However, you can totally use it anywhere else:

enum Test {
    V1
}

impl Test {
    fn func(&self) -> i32 {
        12
    }
}

fn main() {
    const FOO: Test = Test::V1;

    FOO.func(); // here is good
    let x = FOO.func(); // or even here!
}Run

#[deny(const_err)]

const X: i32 = 42 / 0;
// error: attempt to divide by zero in a constant expressionRun

E0022

Constant functions are not allowed to mutate anything. Thus, binding to an argument with a mutable pattern is not allowed. For example,

const fn foo(mut x: u8) {
    // do stuff
}Run

Is incorrect because the function body may not mutate x.

Remove any mutable bindings from the argument list to fix this error. In case you need to mutate the argument, try lazily initializing a global variable instead of using a const fn, or refactoring the code to a functional style to avoid mutation if possible.

E0023

A pattern used to match against an enum variant must provide a sub-pattern for each field of the enum variant. This error indicates that a pattern attempted to extract an incorrect number of fields from a variant.

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

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

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) => {},
}Run

Check how many fields the enum was declared with and ensure that your pattern uses the same number.

E0025

Each field of a struct can only be bound once in a pattern. Erroneous code example:

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

Each occurrence of a field name binds the value of that field, so to fix this error you will have to remove or alter the duplicate uses of the field name. Perhaps you misspelled another field name? Example:

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

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

    let Foo { a: x, b: y } = x; // ok!
}Run

E0026

This error indicates that a struct pattern attempted to extract a non-existent field from a struct. Struct fields are identified by the name used before the colon : so struct patterns should resemble the declaration of the struct type being matched.

// Correct matching.
struct Thing {
    x: u32,
    y: u32
}

let thing = Thing { x: 1, y: 2 };

match thing {
    Thing { x: xfield, y: yfield } => {}
}Run

If you are using shorthand field patterns but want to refer to the struct field by a different name, you should rename it explicitly.

Change this:

struct Thing {
    x: u32,
    y: u32
}

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

match thing {
    Thing { x, z } => {}
}Run

To this:

struct Thing {
    x: u32,
    y: u32
}

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

match thing {
    Thing { x, y: z } => {}
}Run

E0027

This error indicates that a pattern for a struct fails to specify a sub-pattern for every one of the struct's fields. Ensure that each field from the struct's definition is mentioned in the pattern, or use .. to ignore unwanted fields.

For example:

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

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

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

This is correct (explicit):

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, .. } => {}
}Run

E0029

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.

let string = "salutations !";

// The ordering relation for strings can't 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" => {}
    _ => {}
}Run

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.

For example:

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

E0033

This error indicates that a pointer to a trait type cannot be implicitly dereferenced by a pattern. Every trait defines a type, but because the size of trait implementors 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.

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

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

To avoid this error, you have to keep only one of them and remove the others. So let's take our example and fix it:

struct Test;

trait Trait1 {
    fn foo();
}

impl Trait1 for Test { fn foo() {} }

fn main() {
    Test::foo() // and now that's good!
}Run

However, a better solution would be using fully explicit naming of type and trait:

struct Test;

trait Trait1 {
    fn foo();
}

trait Trait2 {
    fn foo();
}

impl Trait1 for Test { fn foo() {} }
impl Trait2 for Test { fn foo() {} }

fn main() {
    <Test as Trait1>::foo()
}Run

One last example:

trait F {
    fn m(&self);
}

trait G {
    fn m(&self);
}

struct X;

impl F for X { fn m(&self) { println!("I am F"); } }
impl G for X { fn m(&self) { println!("I am G"); } }

fn main() {
    let f = X;

    F::m(&f); // it displays "I am F"
    G::m(&f); // it displays "I am G"
}Run

E0038

Trait objects like Box<Trait> can only be constructed when certain requirements are satisfied by the trait in question.

Trait objects are a form of dynamic dispatch and use a dynamically sized type for the inner type. So, for a given trait Trait, when Trait is treated as a type, as in Box<Trait>, the inner type is 'unsized'. In such cases the boxed pointer is a 'fat pointer' that contains an extra pointer to a table of methods (among other things) for dynamic dispatch. This design mandates some restrictions on the types of traits that are allowed to be used in trait objects, which are collectively termed as 'object safety' rules.

Attempting to create a trait object for a non object-safe trait will trigger this error.

There are various rules:

The trait cannot require Self: Sized

When Trait is treated as a type, the type does not implement the special Sized trait, because the type does not have a known size at compile time and can only be accessed behind a pointer. Thus, if we have a trait like the following:

trait Foo where Self: Sized {

}Run

We cannot create an object of type Box<Foo> or &Foo since in this case Self would not be Sized.

Generally, Self : Sized is used to indicate that the trait should not be used as a trait object. If the trait comes from your own crate, consider removing this restriction.

Method references the Self type in its arguments or return type

This happens when a trait has a method like the following:

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

impl Trait for String {
    fn foo(&self) -> Self {
        "hi".to_owned()
    }
}

impl Trait for u8 {
    fn foo(&self) -> Self {
        1
    }
}Run

(Note that &self and &mut self are okay, it's additional Self types which cause this problem.)

In such a case, the compiler cannot predict the return type of foo() in a situation like the following:

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

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

If only some methods aren't object-safe, you can add a where Self: Sized bound on them to mark them as explicitly unavailable to trait objects. The functionality will still be available to all other implementers, including Box<Trait> which is itself sized (assuming you impl Trait for Box<Trait>).

trait Trait {
    fn foo(&self) -> Self where Self: Sized;
    // more functions
}Run

Now, foo() can no longer be called on a trait object, but you will now be allowed to make a trait object, and that will be able to call any object-safe methods. With such a bound, one can still call foo() on types implementing that trait that aren't behind trait objects.

Method has generic type parameters

As mentioned before, trait objects contain pointers to method tables. So, if we have:

trait Trait {
    fn foo(&self);
}

impl Trait for String {
    fn foo(&self) {
        // implementation 1
    }
}

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

At compile time each implementation of Trait will produce a table containing the various methods (and other items) related to the implementation.

This works fine, but when the method gains generic parameters, we can have a problem.

Usually, generic parameters get monomorphized. For example, if I have

fn foo<T>(x: T) {
    // ...
}Run

The machine code for foo::<u8>(), foo::<bool>(), foo::<String>(), or any other type substitution is different. Hence the compiler generates the implementation on-demand. If you call foo() with a bool parameter, the compiler will only generate code for foo::<bool>(). When we have additional type parameters, the number of monomorphized implementations the compiler generates does not grow drastically, since the compiler will only generate an implementation if the function is called with unparametrized substitutions (i.e., substitutions where none of the substituted types are themselves parametrized).

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 implementationsRun

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");
}Run

We don't just need to create a table of all implementations of all methods of Trait, we need to create such a table, for each different type fed to foo(). In this case this turns out to be (10 types implementing Trait)*(3 types being fed to foo()) = 30 implementations!

With real world traits these numbers can grow drastically.

To fix this, it is suggested to use a where Self: Sized bound similar to the fix for the sub-error above if you do not intend to call the method with type parameters:

trait Trait {
    fn foo<T>(&self, on: T) where Self: Sized;
    // more methods
}Run

If this is not an option, consider replacing the type parameter with another trait object (e.g. if T: OtherTrait, use on: Box<OtherTrait>). If the number of types you intend to feed to this method is limited, consider manually listing out the methods of different types.

Method has no receiver

Methods that do not take a self parameter can't be called since there won't be a way to get a pointer to the method table for them.

trait Foo {
    fn foo() -> u8;
}Run

This could be called as <Foo as Foo>::foo(), which would not be able to pick an implementation.

Adding a Self: Sized bound to these methods will generally make this compile.

trait Foo {
    fn foo() -> u8 where Self: Sized;
}Run

The trait cannot 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> {}

trait Trait: Super<Self> {
}

struct Foo;

impl Super<Foo> for Foo{}

impl Trait for Foo {}Run

Here, the supertrait might have methods as follows:

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

If the trait Foo 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. It is also not necessary to do this since drop is called automatically whenever a value goes out of scope.

Here's an example of this error:

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

E0044

You can't use type parameters on foreign items. Example of erroneous code:

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

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

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

E0045

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. Examples of erroneous code:

#![feature(unboxed_closures)]

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

// or

fn foo(x: u8, ...) {}Run

To fix such code, put them in an extern "C" block:

extern "C" {
    fn foo (x: u8, ...);
}Run

E0046

Items are missing in a trait implementation. Erroneous code example:

trait Foo {
    fn foo();
}

struct Bar;

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

When trying to make some type implement a trait Foo, you must, at minimum, provide implementations for all of Foo's required methods (meaning the methods that do not have default implementations), as well as any required trait items like associated types or constants. Example:

trait Foo {
    fn foo();
}

struct Bar;

impl Foo for Bar {
    fn foo() {} // ok!
}Run

E0049

This error indicates that an attempted implementation of a trait method has the wrong number of type parameters.

For example, the trait below has a method foo with a type parameter T, but the implementation of foo for the type Bar is missing this parameter:

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

E0050

This error indicates that an attempted implementation of a trait method has the wrong number of function parameters.

For example, the trait below has a method foo with two function parameters (&self and u8), but the implementation of foo for the type Bar omits the u8 parameter:

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

E0053

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

Here are a couple examples of this error:

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

E0054

It is not allowed to cast to a bool. If you are trying to cast a numeric type to a bool, you can compare it with zero instead:

let x = 5;

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

let x = 5;

// Ok
let x_is_nonzero = x != 0;Run

E0055

During a method call, a value is automatically dereferenced as many times as needed to make the value's type match the method's receiver. The catch is that the compiler will only attempt to dereference a number of times up to the recursion limit (which can be set via the recursion_limit attribute).

For a somewhat artificial example:

#![recursion_limit="2"]

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

One fix may be to increase the recursion limit. Note that it is possible to create an infinite recursion of dereferencing, in which case the only fix is to somehow break the recursion.

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 parametersRun

fn foo<F: Fn()>(f: F) {
    f(); // this is valid, but f(3) would not work
}Run

E0059

The built-in function traits are generic over a tuple of the function arguments. If one uses angle-bracket notation (Fn<(T,), Output=U>) instead of parentheses (Fn(T) -> U) to denote the function trait, the type parameter should be a tuple. Otherwise function call notation cannot be used and the trait will not be implemented by closures.

The most likely source of this error is using angle-bracket notation without wrapping the function argument type into a tuple, for example:

#![feature(unboxed_closures)]

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

It can be fixed by adjusting the trait bound like this:

#![feature(unboxed_closures)]

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

Note that (T,) always denotes the type of a 1-tuple containing an element of type T. The comma is necessary for syntactic disambiguation.

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

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

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

fn f(a: u16, b: &str) {}Run

E0062

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. Erroneous code example:

struct Foo {
    x: i32,
}

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

Each field should be specified exactly one time. Example:

struct Foo {
    x: i32,
}

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

E0063

This error indicates that during an attempt to build a struct or struct-like enum variant, one of the fields was not provided. Erroneous code example:

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

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

Each field should be specified exactly once. Example:

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

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

E0067

The left-hand side of a compound assignment expression must be an lvalue expression. An lvalue expression represents a memory location and includes item paths (ie, namespaced variables), dereferences, indexing expressions, and field references.

Let's start with some erroneous code examples:

use std::collections::LinkedList;

// Bad: assignment to non-lvalue expression
LinkedList::new() += 1;

// ...

fn some_func(i: &mut i32) {
    i += 12; // Error : '+=' operation cannot be applied on a reference !
}Run

And now some working examples:

let mut i : i32 = 0;

i += 12; // Good !

// ...

fn some_func(i: &mut i32) {
    *i += 12; // Good !
}Run

E0069

The compiler found a function whose body contains a return; statement but whose return type is not (). An example of this is:

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

Since return; is just like return ();, there is a mismatch between the function's return type and the value being returned.

E0070

The left-hand side of an assignment operator must be an lvalue expression. An lvalue 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.

Now, we can go further. Here are some 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 lvalue!
    some_other_func() = 4; // error : we can't assign value to a function!
    SomeStruct.x = 12; // error : SomeStruct a structure name but it is used
                       // like a variable!
}Run

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

E0071

You tried to use structure-literal syntax 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`Run

To fix this, ensure that the name was correctly spelled, and that the correct form of initializer was used.

For example, the code above can be fixed to:

enum Foo {
    FirstValue(i32)
}

fn main() {
    let u = Foo::FirstValue(0i32);

    let t = 4;
}Run

E0072

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 &). 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.

Consider the following erroneous definition of a type for a list of bytes:

// error, invalid recursive struct type
struct ListNode {
    head: u8,
    tail: Option<ListNode>,
}Run

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

This works because Box is a pointer, so its size is well-known.

struct Foo { x: Box<Foo> } // errorRun

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

#![feature(repr_simd)]

#[repr(simd)]
struct Bad<T>(T, T, T);Run

#![feature(repr_simd)]

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

E0075

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.

This will cause an error:

#![feature(repr_simd)]

#[repr(simd)]
struct Bad;Run

This will not:

#![feature(repr_simd)]

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

E0076

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.

This will cause an error:

#![feature(repr_simd)]

#[repr(simd)]
struct Bad(u16, u32, u32);Run

This will not:

#![feature(repr_simd)]

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

E0077

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.

This will cause an error:

#![feature(repr_simd)]

#[repr(simd)]
struct Bad(String);Run

This will not:

#![feature(repr_simd)]

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

E0080

This error indicates that the compiler was unable to sensibly evaluate an constant expression that had to be evaluated. Attempting to divide by 0 or causing integer overflow are two ways to induce this error. For example:

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

Ensure that the expressions given can be evaluated as the desired integer type. See the FFI section of the Reference for more information about using a custom integer type:

https://doc.rust-lang.org/reference.html#ffi-attributes

E0081

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 them impossible to tell apart.

// Bad.
enum Enum {
    P = 3,
    X = 3,
    Y = 5,
}Run

// Good.
enum Enum {
    P,
    X = 3,
    Y = 5,
}Run

Note that variants without a manually specified discriminant are numbered from top to bottom starting from 0, so clashes can occur with seemingly unrelated variants.

enum Bad {
    X,
    Y = 0
}Run

Here X will have already been specified the discriminant 0 by the time Y is encountered, so a conflict occurs.

#[repr(u8)]
enum Thing {
    A = 1024,
    B = 5,
}Run

enum DependsOnPointerSize {
    A = 1 << 32,
}Run

E0084

An unsupported representation was attempted on a zero-variant enum.

Erroneous code example:

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

It is impossible to define an integer type to be used to represent zero-variant enum values because there are no zero-variant enum values. There is no way to construct an instance of the following type using only safe code. So you have two solutions. Either you add variants in your enum:

#[repr(i32)]
enum NightsWatch {
    JonSnow,
    Commander,
}Run

or you remove the integer represention of your enum:

enum NightsWatch {}Run

E0087

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

fn foo<T>() {}

fn main() {
    foo::<f64, bool>(); // error, expected 1 parameter, found 2 parameters
}Run

The number of supplied parameters must exactly match the number of defined type parameters.

E0088

You gave too many lifetime parameters. Erroneous code example:

fn f() {}

fn main() {
    f::<'static>() // error: too many lifetime parameters provided
}Run

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

fn f() {}

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

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

struct Foo {
    value: String
}

impl Foo {
    // 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());
}Run

E0089

Not enough type parameters were supplied for a function. For example:

fn foo<T, U>() {}

fn main() {
    foo::<f64>(); // error, expected 2 parameters, found 1 parameter
}Run

Note that if a function takes multiple type parameters 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, expected 2 parameters, found 1 parameter
    foo::<_, f64>(x); // same as `foo::<bool, f64>(x)`
}Run

E0090

You gave too few lifetime parameters. Example:

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

fn main() {
    foo::<'static>(); // error, expected 2 lifetime parameters
}Run

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

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

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

E0091

You gave an unnecessary type parameter 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 unusedRun

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

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

E0092

You tried to declare an undefined atomic operation function. Erroneous code example:

#![feature(intrinsics)]

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

Please check you didn't make a mistake in the function's name. All intrinsic functions are defined in librustc_trans/trans/intrinsic.rs and in libcore/intrinsics.rs in the Rust source code. Example:

#![feature(intrinsics)]

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

E0093

You declared an unknown intrinsic function. Erroneous code example:

#![feature(intrinsics)]

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

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

Please check you didn't make a mistake in the function's name. All intrinsic functions are defined in librustc_trans/trans/intrinsic.rs and in libcore/intrinsics.rs in the Rust source code. Example:

#![feature(intrinsics)]

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

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

E0094

You gave an invalid number of type parameters 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
}Run

Please check that you provided the right number of type parameters and verify with the function declaration in the Rust source code. Example:

#![feature(intrinsics)]

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

E0106

This error indicates that a lifetime is missing from a type. If it is an error inside a function signature, the problem may be with failing to adhere to the lifetime elision rules (see below).

Here are some simple examples of where you'll run into this error:

struct Foo { x: &bool }        // error
struct Foo<'a> { x: &'a bool } // correct

struct Bar { x: Foo }
               ^^^ expected lifetime parameter
struct Bar<'a> { x: Foo<'a> } // correct

enum Bar { A(u8), B(&bool), }        // error
enum Bar<'a> { A(u8), B(&'a bool), } // correct

type MyStr = &str;        // error
type MyStr<'a> = &'a str; // correctRun

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

Here's an example that is currently an error, but may work in a future version of Rust:

struct Foo<'a>(&'a str);

trait Quux { }
impl Quux for Foo { }Run

Lifetime elision in implementation headers was part of the lifetime elision RFC. It is, however, currently unimplemented.

E0107

This error means that an incorrect number of lifetime parameters were provided for a type (like a struct or enum) or trait:

struct Foo<'a, 'b>(&'a str, &'b str);
enum Bar { A, B, C }

struct Baz<'a> {
    foo: Foo<'a>, // error: expected 2, found 1
    bar: Bar<'a>, // error: expected 0, found 1
}Run

E0109

You tried to give a type parameter to a type which doesn't need it. Erroneous code example:

type X = u32<i32>; // error: type parameters are not allowed on this typeRun

Please check that you used the correct type and recheck its definition. Perhaps it doesn't need the type parameter.

Example:

type X = u32; // this compilesRun

Note that type parameters for enum-variant constructors go after the variant, not after the enum (Option::None::<u32>, not Option::<u32>::None).

E0110

You tried to give a lifetime parameter to a type which doesn't need it. Erroneous code example:

type X = u32<'static>; // error: lifetime parameters are not allowed on
                       //        this typeRun

Please check that the correct type was used and recheck its definition; perhaps it doesn't need the lifetime parameter. Example:

type X = u32; // ok!Run

E0116

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 below is not allowed since Vec is defined in the standard library:

impl Vec<u8> { } // errorRun

To fix this problem, you can do either of these things:

• define a trait that has the desired associated functions/types/constants and implement the trait for the type in question
• define a new type wrapping the type and define an implementation on the new type

Note that using the type keyword does not work here because type only introduces a type alias:

type Bytes = Vec<u8>;

impl Bytes { } // error, same as aboveRun

E0117

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.

Here's one example of this error:

impl Drop for u32 {}Run

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

Alternatively, define a trait locally and implement that instead:

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

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

For information on the design of the orphan rules, see RFC 1023.

E0118

You're trying to write an inherent implementation for something which isn't a struct nor an enum. Erroneous code example:

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

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

Alternatively, you can create a newtype. A newtype is a wrapping tuple-struct. For example, NewType is a newtype over Foo in struct NewType(Foo). Example:

struct TypeWrapper((u8, u8));

impl TypeWrapper {
    fn get_state(&self) -> String {
        "Fascinating!".to_owned()
    }
}Run

E0119

There are conflicting trait implementations for the same type. Example of erroneous code:

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

When looking for the implementation for the trait, the compiler finds both the impl<T> MyTrait for T where T is all types and the impl MyTrait for Foo. Since a trait cannot be implemented multiple times, this is an error. So, when you write:

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

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

This makes the trait implemented on all types in the scope. So if you try to implement it on another one after that, the implementations will conflict. Example:

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

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

struct Foo;

fn main() {
    let f = Foo;

    f.get(); // the trait is implemented so we can use it
}Run

E0120

An attempt was made to implement Drop on a trait, which is not allowed: only structs and enums can implement Drop. An example causing this error:

trait MyTrait {}

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

A workaround for this problem is to wrap the trait up in a struct, and implement Drop on that. An example is shown below:

trait MyTrait {}
struct MyWrapper<T: MyTrait> { foo: T }

impl <T: MyTrait> Drop for MyWrapper<T> {
    fn drop(&mut self) {}
}
Run

Alternatively, wrapping trait objects requires something like the following:

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

E0121

In order to be consistent with Rust's lack of global type inference, type placeholders are disallowed by design in item signatures.

Examples of this error include:

fn foo() -> _ { 5 } // error, explicitly write out the return type instead

static BAR: _ = "test"; // error, explicitly write out the type insteadRun

E0122

An attempt was made to add a generic constraint to a type alias. This constraint is entirely ignored. For backwards compatibility, Rust still allows this with a warning. Consider the example below:

trait Foo{}

type MyType<R: Foo> = (R, ());

fn main() {
    let t: MyType<u32>;
}Run

We're able to declare a variable of type MyType<u32>, despite the fact that u32 does not implement Foo. As a result, one should avoid using generic constraints in concert with type aliases.

E0124

You declared two fields of a struct with the same name. Erroneous code example:

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

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

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

E0128

Type parameter defaults can only use parameters that occur before them. Erroneous code example:

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

Since type parameters are evaluated in-order, you may be able to fix this issue by doing:

struct Foo<U=(), T=U> {
    field1: T,
    filed2: U,
}Run

Please also verify that this wasn't because of a name-clash and rename the type parameter if so.

E0130

You declared a pattern as an argument in a foreign function declaration. Erroneous code example:

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

Please replace the pattern argument with a regular one. Example:

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

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

Or:

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

E0131

It is not possible to define main with type parameters, or even with function parameters. When main is present, it must take no arguments and return (). Erroneous code example:

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

E0132

A function with the start attribute was declared with type parameters.

Erroneous code example:

#![feature(start)]

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

It is not possible to declare type parameters on a function that has the start attribute. Such a function must have the following type signature (for more information: http://doc.rust-lang.org/stable/book/first-edition/no-stdlib.html):

fn(isize, *const *const u8) -> isize;Run

Example:

#![feature(start)]

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

E0133

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

Erroneous code example:

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

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

Using unsafe functionality is potentially dangerous and disallowed by safety checks. Examples:

• Dereferencing raw pointers
• Calling functions via FFI
• Calling functions marked unsafe

These safety checks can be relaxed for a section of the code by wrapping the unsafe instructions with an unsafe block. For instance:

unsafe fn f() { return; }

fn main() {
    unsafe { f(); } // ok!
}Run

See also https://doc.rust-lang.org/book/first-edition/unsafe.html

E0136

A binary can only have one entry point, and by default that entry point is the function main(). If there are multiple such functions, please rename one.

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] attributeRun

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!Run

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' functionsRun

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!Run

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

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

unsafe {
    ptr::read(&v as *const _ as *const SomeType) // `v` transmuted to `SomeType`
}Run

E0152

A lang item was redefined.

Erroneous code example:

#![feature(lang_items)]

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

Lang items are already implemented in the standard library. Unless you are writing a free-standing application (e.g. a kernel), you do not need to provide them yourself.

You can build a free-standing crate by adding #![no_std] to the crate attributes:

#![no_std]Run

See also https://doc.rust-lang.org/book/first-edition/no-stdlib.html

fn f() {
    // Variable declaration before import
    let x = 0;
    use std::io::Read;
    // ...
}Run

fn f() {
    use std::io::Read;
    let x = 0;
    // ...
}Run

E0158

const and static mean different things. A const is a compile-time constant, an alias for a literal value. This property means you can match it directly within a pattern.

The static keyword, on the other hand, guarantees a fixed location in memory. This does not always mean that the value is constant. For example, a global mutex can be declared static as well.

If you want to match against a static, consider using a guard instead:

static FORTY_TWO: i32 = 42;

match Some(42) {
    Some(x) if x == FORTY_TWO => {}
    _ => {}
}Run

E0161

A value was moved. However, its size was not known at compile time, and only values of a known size can be moved.

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

In Rust, you can only move a value when its size is known at compile time.

To work around this restriction, consider "hiding" the value behind a reference: either &x or &mut x. Since a reference has a fixed size, this lets you move it around as usual. Example:

#![feature(box_syntax)]

fn main() {
    let array: &[isize] = &[1, 2, 3];
    let _x: Box<&[isize]> = box array; // ok!
}Run

E0162

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

Try this instead:

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

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

E0164

This error means that an attempt was made to match a struct type enum variant as a non-struct type:

enum Foo { B { i: u32 } }

fn bar(foo: Foo) -> u32 {
    match foo {
        Foo::B(i) => i, // error E0164
    }
}Run

Try using {} instead:

enum Foo { B { i: u32 } }

fn bar(foo: Foo) -> u32 {
    match foo {
        Foo::B{i} => i,
    }
}Run

E0165

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

Try this instead:

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

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

E0170

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

enum Method {
    GET,
    POST,
}Run

You would match it using:

enum Method {
    GET,
    POST,
}

let m = Method::GET;

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

If you don't qualify the names, the code will bind new variables named "GET" and "POST" instead. This behavior is likely not what you want, so rustc warns when that happens.

Qualified names are good practice, and most code works well with them. But if you prefer them unqualified, you can import the variants into scope:

use Method::*;
enum Method { GET, POST }Run

If you want others to be able to import variants from your module directly, use pub use:

pub use Method::*;
pub enum Method { GET, POST }Run

E0178

In types, the + type operator has low precedence, so it is often necessary to use parentheses.

For example:

trait Foo {}

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

More details can be found in RFC 438.

E0184

Explicitly implementing both Drop and Copy for 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).

Here's an example of this error:

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

E0186

An associated function for a trait was defined to be a method (i.e. to take a self parameter), but an implementation of the trait declared the same function to be static.

Here's an example of this error:

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

E0191

Trait objects need to have all associated types specified. Erroneous code example:

trait Trait {
    type Bar;
}

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

Please verify you specified all associated types of the trait and that you used the right trait. Example:

trait Trait {
    type Bar;
}

type Foo = Trait<Bar=i32>; // ok!Run

E0192

Negative impls are only allowed for traits with default impls. For more information see the opt-in builtin traits RFC.

trait Foo {
    fn bar(&self);
}

#[derive(Copy,Clone)]
struct Wrapper<T> {
    Wrapped: T
}

impl Foo for Wrapper<u32> where Wrapper<u32>: Clone {
    fn bar(&self) { }
}Run

trait Foo {
    fn bar(&self);
}

#[derive(Copy,Clone)]
struct Wrapper<T> {
    Wrapped: T
}
impl <T> Foo for Wrapper<T> where Wrapper<T>: Clone {
    fn bar(&self) { }
}Run

E0194

A type parameter was declared which shadows an existing one. An example of this error:

trait Foo<T> {
    fn do_something(&self) -> T;
    fn do_something_else<T: Clone>(&self, bar: T);
}Run

In this example, the trait Foo and the trait method do_something_else both define a type parameter T. This is not allowed: if the method wishes to define a type parameter, it must use a different name for it.

E0195

Your method's lifetime parameters 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
    }
}Run

The lifetime constraint 'b for bar() implementation does not match the trait declaration. Ensure lifetime declarations match exactly in both trait declaration and implementation. Example:

trait Trait {
    fn t<'a,'b:'a>(x: &'a str, y: &'b str);
}

struct Foo;

impl Trait for Foo {
    fn t<'a,'b:'a>(x: &'a str, y: &'b str) { // ok!
    }
}Run

E0197

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;

// this will cause this error
unsafe impl Foo { }
// converting it to this will fix it
impl Foo { }Run

E0198

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.

#![feature(optin_builtin_traits)]

struct Foo;

// unsafe is unnecessary
unsafe impl !Clone for Foo { }Run

This will compile:

#![feature(optin_builtin_traits)]

struct Foo;

trait Enterprise {}

impl Enterprise for .. { }

impl !Enterprise for Foo { }Run

Please note that negative impls are only allowed for traits with default impls.

E0199

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

// this won't compile because Bar is safe
unsafe impl Bar for Foo { }
// this will compile
impl Bar for Foo { }Run

E0200

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

// this won't compile because Bar is unsafe and impl isn't unsafe
impl Bar for Foo { }
// this will compile
unsafe impl Bar for Foo { }Run

E0201

It is an error to define two associated items (like methods, associated types, associated functions, etc.) with the same identifier.

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

Note, however, that items with the same name are allowed for inherent impl blocks that don't overlap:

struct Foo<T>(T);

impl Foo<u8> {
    fn bar(&self) -> bool { self.0 > 5 }
}

impl Foo<bool> {
    fn bar(&self) -> bool { self.0 }
}Run

E0202

Inherent associated types were part of RFC 195 but are not yet implemented. See the tracking issue for the status of this implementation.

E0204

An attempt to implement the Copy trait for a struct failed because one of the fields does not implement Copy. To fix this, you must implement Copy for the mentioned field. Note that this may not be possible, as in the example of

struct Foo {
    foo : Vec<u32>,
}

impl Copy for Foo { }Run

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

Here's another example that will fail:

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

This fails because &mut T is not Copy, even when T is Copy (this differs from the behavior for &T, which is always Copy).

E0206

You can only implement Copy for a struct or enum. Both of the following examples will fail, because neither i32 (primitive type) nor &'static Bar (reference to Bar) is a struct or enum:

type Foo = i32;
impl Copy for Foo { } // error

#[derive(Copy, Clone)]
struct Bar;
impl Copy for &'static Bar { } // errorRun

E0207

Any type parameter or lifetime parameter of an impl must meet at least one of the following criteria:

• it appears in the self type of the impl
• for a trait impl, it appears in the trait reference
• it is bound as an associated type

Error example 1

Suppose we have a struct Foo and we would like to define some methods for it. The following definition leads to a compiler error:

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

The problem is that the parameter T does not appear in the self 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()
    }
}Run

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

This fails to compile because T does not appear in the trait or in the implementing type.

One way to work around this is to introduce a phantom type parameter into FooMaker, like so:

use std::marker::PhantomData;

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

struct Foo<T> {
    foo: T
}

// 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(),
        }
    }
}Run

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

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. To understand what this means, it is perhaps easiest 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 { } // errorRun

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

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

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

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

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

where P1, ..., Pm are the type parameters of the impl and T0, ..., Tn are types. One of the types T0, ..., Tn must be a local type (this is another orphan rule, see the explanation for E0117). Let i be the smallest integer such that Ti is a local type. Then no type parameter can appear in any of the Tj for j < i.

For information on the design of the orphan rules, see RFC 1023.

E0214

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

fn main() {
    let v: Vec(&str) = vec!["foo"];
}Run

This is not currently supported: v should be defined as Vec<&str>. Parentheses are currently only used with generic types when defining parameters for Fn-family traits.

E0220

You used an associated type which isn't 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;
}Run

Make sure that you have defined the associated type in the trait body. Also, verify that you used the right trait or you didn't misspell the associated type name. Example:

trait T1 {
    type Bar;
}

type Foo = T1<Bar=i32>; // 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;
}Run

E0221

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

trait T1 {}
trait T2 {}

trait Foo {
    type A: T1;
}

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

In this example, Foo defines an associated type A. Bar inherits that type from Foo, and defines another associated type of the same name. As a result, when we attempt to use Self::A, it's ambiguous whether we mean the A defined by Foo or the one defined by Bar.

There are two options to work around this issue. The first is simply to rename one of the types. Alternatively, one can specify the intended type using the following syntax:

trait T1 {}
trait T2 {}

trait Foo {
    type A: T1;
}

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

E0223

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

trait MyTrait {type X; }

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

The problem here is that we're attempting to take the type of X from MyTrait. Unfortunately, the type of X is not defined, because it's only made concrete in implementations of the trait. A working version of this code might look like:

trait MyTrait {type X; }
struct MyStruct;

impl MyTrait for MyStruct {
    type X = u32;
}

fn main() {
    let foo: <MyStruct as MyTrait>::X;
}Run

This syntax specifies that we want the X type from MyTrait, as made concrete in MyStruct. The reason that we cannot simply use MyStruct::X is that MyStruct might implement two different traits with identically-named associated types. This syntax allows disambiguation between the two.

E0225

You attempted to use multiple types as bounds for a closure or trait object. Rust does not currently support this. A simple example that causes this error:

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

Send and Sync are an exception to this rule: it's possible to have bounds of one non-builtin trait, plus either or both of Send and Sync. For example, the following compiles correctly:

fn main() {
    let _: Box<std::io::Read + Send + Sync>;
}Run

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 hereRun

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!Run

Or in the where clause:

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

E0230

The #[rustc_on_unimplemented] attribute lets you specify a custom error message for when a particular trait isn't implemented on a type placed in a position that needs that trait. For example, when the following code is compiled:

#![feature(on_unimplemented)]

fn foo<T: Index<u8>>(x: T){}

#[rustc_on_unimplemented = "the type `{Self}` cannot be indexed by `{Idx}`"]
trait Index<Idx> { /* ... */ }

foo(true); // `bool` does not implement `Index<u8>`Run

There will be an error about bool not implementing Index<u8>, followed by a note saying "the type bool cannot be indexed by u8".

As you can see, you can specify type parameters in curly braces for substitution with the actual types (using the regular format string syntax) in a given situation. Furthermore, {Self} will substitute to the type (in this case, bool) that we tried to use.

This error appears when the curly braces contain an identifier which doesn't match with any of the type parameters or the string Self. This might happen if you misspelled a type parameter, or if you intended to use literal curly braces. If it is the latter, escape the curly braces with a second curly brace of the same type; e.g. a literal { is {{.

E0231

The #[rustc_on_unimplemented] attribute lets you specify a custom error message for when a particular trait isn't implemented on a type placed in a position that needs that trait. For example, when the following code is compiled:

#![feature(on_unimplemented)]

fn foo<T: Index<u8>>(x: T){}

#[rustc_on_unimplemented = "the type `{Self}` cannot be indexed by `{Idx}`"]
trait Index<Idx> { /* ... */ }

foo(true); // `bool` does not implement `Index<u8>`Run

there will be an error about bool not implementing Index<u8>, followed by a note saying "the type bool cannot be indexed by u8".

As you can see, you can specify type parameters in curly braces for substitution with the actual types (using the regular format string syntax) in a given situation. Furthermore, {Self} will substitute to the type (in this case, bool) that we tried to use.

This error appears when the curly braces do not contain an identifier. Please add one of the same name as a type parameter. If you intended to use literal braces, use {{ and }} to escape them.

E0232

The #[rustc_on_unimplemented] attribute lets you specify a custom error message for when a particular trait isn't implemented on a type placed in a position that needs that trait. For example, when the following code is compiled:

#![feature(on_unimplemented)]

fn foo<T: Index<u8>>(x: T){}

#[rustc_on_unimplemented = "the type `{Self}` cannot be indexed by `{Idx}`"]
trait Index<Idx> { /* ... */ }

foo(true); // `bool` does not implement `Index<u8>`Run

there will be an error about bool not implementing Index<u8>, followed by a note saying "the type bool cannot be indexed by u8".

For this to work, some note must be specified. An empty attribute will not do anything, please remove the attribute or add some helpful note for users of the trait.

E0243

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

E0244

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

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

E0252

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

Erroneous code example:

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

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

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

E0253

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

Erroneous code example:

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

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

fn main() {}Run

It's invalid to directly import methods belonging to a trait or concrete type.

E0254

Attempt was made to import an item whereas an extern crate with this name has already been imported.

Erroneous code example:

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

To fix issue 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() {}Run

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

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

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

use foo::Bar; // error

type Bar = u32;

mod foo {
    pub mod Bar { }
}

fn main() {}Run

E0259

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

Erroneous code example:

extern crate core;
extern crate libc as core;

fn main() {}Run

The solution is to choose a different name that doesn't conflict with any external crate imported into the current module.

Correct example:

extern crate core;
extern crate libc as other_name;

fn main() {}Run

E0260

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

Erroneous code example:

extern crate core;

struct core;Run

There are two possible solutions:

Solution #1: Rename the item.

extern crate core;

struct xyz;Run

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

extern crate core as xyz;

struct abc;Run

See the Declaration Statements section of the reference for more information about what constitutes an Item declaration and what does not:

https://doc.rust-lang.org/reference.html#statements

E0261

When using a lifetime like 'a in a type, it must be declared before being used.

These two examples illustrate the problem:

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

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

These can be fixed by declaring lifetime parameters:

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

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

E0262

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:

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

E0263

A lifetime name cannot be declared more than once in the same scope. For example:

// error, lifetime name `'a` declared twice in the same scope
fn foo<'a, 'b, 'a>(x: &'a str, y: &'b str) { }Run

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

A list of available external lang items is available in src/librustc/middle/weak_lang_items.rs. Example:

#![feature(lang_items)]

extern "C" {
    #[lang = "panic_fmt"] // ok!
    fn cake();
}Run

E0265

This error indicates that a static or constant references itself. All statics and constants need to resolve to a value in an acyclic manner.

For example, neither of the following can be sensibly compiled:

const X: u32 = X;Run

const X: u32 = Y;
const Y: u32 = X;Run

E0267

This error indicates the use of a loop keyword (break or continue) inside a closure but outside of any loop. Erroneous code example:

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

break and continue keywords can be used as normal inside closures as long as they are also contained within a loop. To halt the execution of a closure you should instead use a return statement. Example:

let w = || {
    for _ in 0..10 {
        break;
    }
};

w();Run

E0268

This error indicates the use of a loop keyword (break or continue) outside of a loop. Without a loop to break out of or continue in, no sensible action can be taken. Erroneous code example:

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

Please verify that you are using break and continue only in loops. Example:

fn some_func() {
    for _ in 0..10 {
        break; // ok!
    }
}Run

E0271

This is because of a type mismatch between the associated type of some trait (e.g. T::Bar, where T implements trait Quux { type Bar; }) and another type U that is required to be equal to T::Bar, but is not. Examples follow.

Here is a basic example:

trait Trait { type AssociatedType; }

fn foo<T>(t: T) where T: Trait<AssociatedType=u32> {
    println!("in foo");
}

impl Trait for i8 { type AssociatedType = &'static str; }

foo(3_i8);Run

Here is that same example again, with some explanatory comments:

trait Trait { type AssociatedType; }

fn foo<T>(t: T) where T: Trait<AssociatedType=u32> {
//                    ~~~~~~~~ ~~~~~~~~~~~~~~~~~~
//                        |            |
//         This says `foo` can         |
//           only be used with         |
//              some type that         |
//         implements `Trait`.         |
//                                     |
//                             This says not only must
//                             `T` be an impl of `Trait`
//                             but also that the impl
//                             must assign the type `u32`
//                             to the associated type.
    println!("in foo");
}

impl Trait for i8 { type AssociatedType = &'static str; }
//~~~~~~~~~~~~~~~   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
//      |                             |
// `i8` does have                     |
// implementation                     |
// of `Trait`...                      |
//                     ... but it is an implementation
//                     that assigns `&'static str` to
//                     the associated type.

foo(3_i8);
// Here, we invoke `foo` with an `i8`, which does not satisfy
// the constraint `<i8 as Trait>::AssociatedType=u32`, and
// therefore the type-checker complains with this error code.Run

Here is a more subtle instance of the same problem, that can arise with for-loops in Rust:

let vs: Vec<i32> = vec![1, 2, 3, 4];
for v in &vs {
    match v {
        1 => {},
        _ => {},
    }
}Run

The above fails because of an analogous type mismatch, though may be harder to see. Again, here are some explanatory comments for the same example:

{
    let vs = vec![1, 2, 3, 4];

    // `for`-loops use a protocol based on the `Iterator`
    // trait. Each item yielded in a `for` loop has the
    // type `Iterator::Item` -- that is, `Item` is the
    // associated type of the concrete iterator impl.
    for v in &vs {
//      ~    ~~~
//      |     |
//      |    We borrow `vs`, iterating over a sequence of
//      |    *references* of type `&Elem` (where `Elem` is
//      |    vector's element type). Thus, the associated
//      |    type `Item` must be a reference `&`-type ...
//      |
//  ... and `v` has the type `Iterator::Item`, as dictated by
//  the `for`-loop protocol ...

        match v {
            1 => {}
//          ~
//          |
// ... but *here*, `v` is forced to have some integral type;
// only types like `u8`,`i8`,`u16`,`i16`, et cetera can
// match the pattern `1` ...

            _ => {}
        }

// ... therefore, the compiler complains, because it sees
// an attempt to solve the equations
// `some integral-type` = type-of-`v`
//                      = `Iterator::Item`
//                      = `&Elem` (i.e. `some reference type`)
//
// which cannot possibly all be true.

    }
}Run

To avoid those issues, you have to make the types match correctly. So we can fix the previous examples like this:

// Basic Example:
trait Trait { type AssociatedType; }

fn foo<T>(t: T) where T: Trait<AssociatedType = &'static str> {
    println!("in foo");
}

impl Trait for i8 { type AssociatedType = &'static str; }

foo(3_i8);

// For-Loop Example:
let vs = vec![1, 2, 3, 4];
for v in &vs {
    match v {
        &1 => {}
        _ => {}
    }
}Run

E0275

This error occurs when there was a recursive trait requirement that overflowed before it could be evaluated. Often this means that there is unbounded recursion in resolving some type bounds.

For example, in the following code:

trait Foo {}

struct Bar<T>(T);

impl<T> Foo for T where Bar<T>: Foo {}Run

To determine if a T is Foo, we need to check if Bar<T> is Foo. However, to do this check, we need to determine that Bar<Bar<T>> is Foo. To determine this, we check if Bar<Bar<Bar<T>>> is Foo, and so on. This is clearly a recursive requirement that can't be resolved directly.

Consider changing your trait bounds so that they're less self-referential.

E0276

This error occurs when a bound in an implementation of a trait does not match the bounds specified in the original trait. For example:

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

impl Foo for bool {
    fn foo<T>(x: T) where T: Copy {}
}Run

Here, all types implementing Foo must have a method foo<T>(x: T) which can take any type T. However, in the impl for bool, we have added an extra bound that T is Copy, which isn't compatible with the original trait.

Consider removing the bound from the method or adding the bound to the original method definition in the trait.

E0277

You tried to use a type which doesn't implement some trait in a place which expected that trait. Erroneous code example:

// here we declare the Foo trait with a bar method
trait Foo {
    fn bar(&self);
}

// we now declare a function which takes an object implementing the Foo trait
fn some_func<T: Foo>(foo: T) {
    foo.bar();
}

fn main() {
    // we now call the method with the i32 type, which doesn't implement
    // the Foo trait
    some_func(5i32); // error: the trait bound `i32 : Foo` is not satisfied
}Run

In order to fix this error, verify that the type you're using does implement the trait. Example:

trait Foo {
    fn bar(&self);
}

fn some_func<T: Foo>(foo: T) {
    foo.bar(); // we can now use this method since i32 implements the
               // Foo trait
}

// we implement the trait on the i32 type
impl Foo for i32 {
    fn bar(&self) {}
}

fn main() {
    some_func(5i32); // ok!
}Run

Or in a generic context, an erroneous code example would look like:

fn some_func<T>(foo: T) {
    println!("{:?}", foo); // error: the trait `core::fmt::Debug` is not
                           //        implemented for the type `T`
}

fn main() {
    // We now call the method with the i32 type,
    // which *does* implement the Debug trait.
    some_func(5i32);
}Run

Note that the error here is in the definition of the generic function: Although we only call it with a parameter that does implement Debug, the compiler still rejects the function: It must work with all possible input types. In order to make this example compile, we need to restrict the generic type we're accepting:

use std::fmt;

// Restrict the input type to types that implement Debug.
fn some_func<T: fmt::Debug>(foo: T) {
    println!("{:?}", foo);
}

fn main() {
    // Calling the method is still fine, as i32 implements Debug.
    some_func(5i32);

    // This would fail to compile now:
    // struct WithoutDebug;
    // some_func(WithoutDebug);
}Run

Rust only looks at the signature of the called function, as such it must already specify all requirements that will be used for every type parameter.

fn foo<F: Fn(usize)>(x: F) { }

fn main() {
    // type mismatch: ... implements the trait `core::ops::Fn<(String,)>`,
    // but the trait `core::ops::Fn<(usize,)>` is required
    // [E0281]
    foo(|y: String| { });
}

E0282

This error indicates that type inference did not result in one unique possible type, and extra information is required. In most cases this can be provided by adding a type annotation. Sometimes you need to specify a generic type parameter manually.

A common example is the collect method on Iterator. It has a generic type parameter with a FromIterator bound, which for a char iterator is implemented by Vec and String among others. Consider the following snippet that reverses the characters of a string:

let x = "hello".chars().rev().collect();Run

In this case, the compiler cannot infer what the type of x should be: Vec<char> and String are both suitable candidates. To specify which type to use, you can use a type annotation on x:

let x: Vec<char> = "hello".chars().rev().collect();Run

It is not necessary to annotate the full type. Once the ambiguity is resolved, the compiler can infer the rest:

let x: Vec<_> = "hello".chars().rev().collect();Run

Another way to provide the compiler with enough information, is to specify the generic type parameter:

let x = "hello".chars().rev().collect::<Vec<char>>();Run

Again, you need not specify the full type if the compiler can infer it:

let x = "hello".chars().rev().collect::<Vec<_>>();Run

Apart from a method or function with a generic type parameter, this error can occur when a type parameter of a struct or trait cannot be inferred. In that case it is not always possible to use a type annotation, because all candidates have the same return type. For instance:

struct Foo<T> {
    num: T,
}

impl<T> Foo<T> {
    fn bar() -> i32 {
        0
    }

    fn baz() {
        let number = Foo::bar();
    }
}Run

This will fail because the compiler does not know which instance of Foo to call bar on. Change Foo::bar() to Foo::<T>::bar() to resolve the error.

E0283

This error occurs when the compiler doesn't have enough information to unambiguously choose an implementation.

For example:

trait Generator {
    fn create() -> u32;
}

struct Impl;

impl Generator for Impl {
    fn create() -> u32 { 1 }
}

struct AnotherImpl;

impl Generator for AnotherImpl {
    fn create() -> u32 { 2 }
}

fn main() {
    let cont: u32 = Generator::create();
    // error, impossible to choose one of Generator trait implementation
    // Impl or AnotherImpl? Maybe anything else?
}Run

To resolve this error use the concrete type:

trait Generator {
    fn create() -> u32;
}

struct AnotherImpl;

impl Generator for AnotherImpl {
    fn create() -> u32 { 2 }
}

fn main() {
    let gen1 = AnotherImpl::create();

    // if there are multiple methods with same name (different traits)
    let gen2 = <AnotherImpl as Generator>::create();
}Run

E0296

This error indicates that the given recursion limit could not be parsed. Ensure that the value provided is a positive integer between quotes.

Erroneous code example:

#![recursion_limit]

fn main() {}Run

And a working example:

#![recursion_limit="1000"]

fn main() {}Run

let xs : Vec<Option<i32>> = vec![Some(1), None];

// This fails because `None` is not covered.
for Some(x) in xs {
    // ...
}Run

let xs : Vec<Option<i32>> = vec![Some(1), None];

for item in xs {
    match item {
        Some(x) => {},
        None => {},
    }
}Run

let xs : Vec<Option<i32>> = vec![Some(1), None];

for item in xs {
    if let Some(x) = item {
        // ...
    }
}Run

E0301

Mutable borrows are not allowed in pattern guards, because matching cannot have side effects. Side effects could alter the matched object or the environment on which the match depends in such a way, that the match would not be exhaustive. For instance, the following would not match any arm if mutable borrows were allowed:

match Some(()) {
    None => { },
    option if option.take().is_none() => {
        /* impossible, option is `Some` */
    },
    Some(_) => { } // When the previous match failed, the option became `None`.
}Run

E0302

Assignments are not allowed in pattern guards, because matching cannot have side effects. Side effects could alter the matched object or the environment on which the match depends in such a way, that the match would not be exhaustive. For instance, the following would not match any arm if assignments were allowed:

match Some(()) {
    None => { },
    option if { option = None; false } => { },
    Some(_) => { } // When the previous match failed, the option became `None`.
}Run

E0303

In certain cases it is possible for sub-bindings to violate memory safety. Updates to the borrow checker in a future version of Rust may remove this restriction, but for now patterns must be rewritten without sub-bindings.

Before:

match Some("hi".to_string()) {
    ref op_string_ref @ Some(s) => {},
    None => {},
}Run

After:

match Some("hi".to_string()) {
    Some(ref s) => {
        let op_string_ref = &Some(s);
        // ...
    },
    None => {},
}Run

The op_string_ref binding has type &Option<&String> in both cases.

See also https://github.com/rust-lang/rust/issues/14587

E0308

This error occurs when the compiler was unable to infer the concrete type of a variable. It can occur for several cases, the most common of which is a mismatch in the expected type that the compiler inferred for a variable's initializing expression, and the actual type explicitly assigned to the variable.

For example:

let x: i32 = "I am not a number!";
//     ~~~   ~~~~~~~~~~~~~~~~~~~~
//      |             |
//      |    initializing expression;
//      |    compiler infers type `&str`
//      |
//    type `i32` assigned to variable `x`Run

E0309

Types in type definitions have lifetimes associated with them that represent how long the data stored within them is guaranteed to be live. This lifetime must be as long as the data needs to be alive, and missing the constraint that denotes this will cause this error.

// This won't compile because T is not constrained, meaning the data
// stored in it is not guaranteed to last as long as the reference
struct Foo<'a, T> {
    foo: &'a T
}Run

This will compile, because it has the constraint on the type parameter:

struct Foo<'a, T: 'a> {
    foo: &'a T
}Run

To see why this is important, consider the case where T is itself a reference (e.g., T = &str). If we don't include the restriction that T: 'a, the following code would be perfectly legal:

struct Foo<'a, T> {
    foo: &'a T
}

fn main() {
    let v = "42".to_string();
    let f = Foo{foo: &v};
    drop(v);
    println!("{}", f.foo); // but we've already dropped v!
}Run

E0310

Types in type definitions have lifetimes associated with them that represent how long the data stored within them is guaranteed to be live. This lifetime must be as long as the data needs to be alive, and missing the constraint that denotes this will cause this error.

// This won't compile because T is not constrained to the static lifetime
// the reference needs
struct Foo<T> {
    foo: &'static T
}Run

This will compile, because it has the constraint on the type parameter:

struct Foo<T: 'static> {
    foo: &'static T
}Run