Rust Compiler Error Index

E0001

This error suggests that the expression arm corresponding to the noted pattern will never be reached as for all possible values of the expression being matched, one of the preceding patterns will match.

This means that perhaps some of the preceding patterns are too general, this one is too specific or the ordering is incorrect.

E0002

This error indicates that an empty match expression is illegal because the type it is matching on is non-empty (there exist values of this type). In safe code it is impossible to create an instance of an empty type, so empty match expressions are almost never desired. This error is typically fixed by adding one or more cases to the match expression.

An example of an empty type is enum Empty { }.

E0003

Not-a-Number (NaN) values cannot be compared for equality and hence can never match the input to a match expression. To match against NaN values, you should instead use the is_nan method in a guard, as in: x if x.is_nan() => ...

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.

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".

E0005

Patterns used to bind names must be irrefutable, that is, they must guarantee that a name will be extracted in all cases. If you encounter this error you probably need to use a match or if let to deal with the possibility of failure.

E0006

Patterns used to bind names must be irrefutable, that is, they must guarantee that a name will be extracted in all cases. If you encounter this error you probably need to use a match or if let to deal with the possibility of failure.

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) => ...
    None => ...
}

See also Error 303.

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

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 become unavailable in the body of the arm. Although this example seems innocuous, the problem is most clear when considering functions that take their argument by value.

match Some("hi".to_string()) {
    Some(s) if { drop(s); false } => (),
    Some(s) => // use s.
    ...
}

The value would be dropped in the guard then become unavailable not only in the body of that arm but also in all subsequent arms! The solution is to bind by reference when using guards or refactor the entire expression, perhaps by putting the condition inside the body of the arm.

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.

Wrong example:

struct X { x: (), }

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

You have two solutions:

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

struct X { x: (), }

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

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

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

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

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

E0010

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

E0011

Initializers for constants and statics are evaluated at compile time. User-defined operators rely on user-defined functions, which cannot be evaluated at compile time.

Bad example:

use std::ops::Index;

struct Foo { a: u8 }

impl Index<u8> for Foo {
    type Output = u8;

    fn index<'a>(&'a self, idx: u8) -> &'a u8 { &self.a }
}

const a: Foo = Foo { a: 0u8 };
const b: u8 = a[0]; // Index trait is defined by the user, bad!

Only operators on builtin types are allowed.

Example:

const a: &'static [i32] = &[1, 2, 3];
const b: i32 = a[0]; // Good!

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;

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

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

E0014

Constants can only be initialized by a constant value or, in a future version of Rust, a call to a const function. This error indicates the use of a path (like a::b, or x) denoting something other than one of these allowed items. Example:

const FOO: i32 = { let x = 0; x }; // 'x' isn't a constant nor a function!

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

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

E0015

The only functions that can be called in static or constant expressions are const functions. Rust currently does not support more general compile-time function execution.

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. Example:

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

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

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

E0018

The value of static and const variables must be known at compile time. You can't cast a pointer as an integer because we can't know what value the address will take.

However, pointers to other constants' addresses are allowed in constants, example:

const X: u32 = 50;
const Y: *const u32 = &X;

Therefore, casting one of these non-constant pointers to an integer results in a non-constant integer which lead to this error. Example:

const X: u32 = 1;
const Y: usize = &X as *const u32 as usize;
println!("{}", Y);

E0019

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

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

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

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

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

E0020

This error indicates that an attempt was made to divide by zero (or take the remainder of a zero divisor) in a static or constant expression.

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

Here the Apple variant has two fields, and should be matched against like so:

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

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

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

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

E0024

This error indicates that a pattern attempted to extract the fields of an enum variant with no fields. Here's a tiny example of this error:

// This enum has two variants.
enum Number {
    // This variant has no fields.
    Zero,
    // This variant has one field.
    One(u32)
}

// Assuming x is a Number we can pattern match on its contents.
match x {
    Zero(inside) => ...,
    One(inside) => ...
}

The pattern match Zero(inside) is incorrect because the Zero variant contains no fields, yet the inside name attempts to bind the first field of the enum.

E0025

Each field of a struct can only be bound once in a pattern. Each occurrence of a field name binds the value of that field, so to fix this error you will have to remove or alter the duplicate uses of the field name. Perhaps you misspelt another field name?

E0026

This error indicates that a struct pattern attempted to extract a non-existant 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 } => ...
}

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:
match thing {
    Thing { x, z } => ...
}

// To this:
match thing {
    Thing { x, y: z } => ...
}

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

// This is correct (explicit).
match d {
    Dog { name: n, age: x } => ...
}

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

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.

// 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" => ...
    _ => ...
}

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

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

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

You can read more about trait objects in the Trait Object section of the Reference:

http://doc.rust-lang.org/reference.html#trait-objects

E0034

The compiler doesn't know what method to call because more than one method has the same prototype. Example:

struct Test;

trait Trait1 {
    fn foo();
}

trait Trait2 {
    fn foo();
}

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

fn main() {
    Test::foo() // error, which foo() to call?
}

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

struct Test;

trait Trait1 {
    fn foo();
}

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

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

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

struct Test;

trait Trait1 {
    fn foo();
}

trait Trait2 {
    fn foo();
}

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

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

E0035

You tried to give a type parameter where it wasn't needed. Bad example:

struct Test;

impl Test {
    fn method(&self) {}
}

fn main() {
    let x = Test;

    x.method::<i32>(); // Error: Test::method doesn't need type parameter!
}

To fix this error, just remove the type parameter:

struct Test;

impl Test {
    fn method(&self) {}
}

fn main() {
    let x = Test;

    x.method(); // OK, we're good!
}

E0036

This error occurrs when you pass too many or not enough type parameters to a method. Example:

struct Test;

impl Test {
    fn method<T>(&self, v: &[T]) -> usize {
        v.len()
    }
}

fn main() {
    let x = Test;
    let v = &[0i32];

    x.method::<i32, i32>(v); // error: only one type parameter is expected!
}

To fix it, just specify a correct number of type parameters:

struct Test;

impl Test {
    fn method<T>(&self, v: &[T]) -> usize {
        v.len()
    }
}

fn main() {
    let x = Test;
    let v = &[0i32];

    x.method::<i32>(v); // OK, we're good!
}

Please note on the last example that we could have called method like this:

x.method(v);

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
}

E0044

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

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

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

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:

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

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

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

E0046

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.

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

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

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, values differ in mutability
    fn bar(&mut self) { }
}

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;

// Ok
let x_is_nonzero = x != 0;

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

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

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

E0057

When invoking closures or other implementations of the function traits Fn, FnMut or FnOnce using call notation, the number of parameters passed to the function must match its definition.

An example using a closure:

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

A generic function must be treated similarly:

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

E0059

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

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

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

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

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

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

E0060

External C functions are allowed to be variadic. However, a variadic function takes a minimum number of arguments. For example, consider C's variadic printf function:

extern crate libc;
use libc::{ c_char, c_int };

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

Using this declaration, it must be called with at least one argument, so simply calling printf() is illegal. But the following uses are allowed:

unsafe {
    use std::ffi::CString;

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

E0061

The number of arguments passed to a function must match the number of arguments specified in the function signature.

For example, a function like

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

must always be called with exactly two arguments, e.g. f(2, "test").

Note, that Rust does not have a notion of optional function arguments or variadic functions (except for its C-FFI).

E0062

This error indicates that during an attempt to build a struct or struct-like enum variant, one of the fields was specified more than once. Each field should be specified exactly one time.

E0063

This error indicates that during an attempt to build a struct or struct-like enum variant, one of the fields was not provided. Each field should be specified exactly once.

E0066

Box placement expressions (like C++'s "placement new") do not yet support any place expression except the exchange heap (i.e. std::boxed::HEAP). Furthermore, the syntax is changing to use in instead of box. See RFC 470 and RFC 809 for more details.

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

And now some good examples: ``` let mut i : i32 = 0;

i += 12; // Good !

// ...

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

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

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 here: https://doc.rust-lang.org/reference.html#lvalues,-rvalues-and-temporaries

Now, we can go further. Here are some bad 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! } ```

And now let's give good examples:

struct SomeStruct {
    x: i32,
    y: i32
}
let mut s = SomeStruct {x: 0, y: 0};

s.x = 3; // that's good !

// ...

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

E0071

You tried to use a structure initialization with a non-structure type. Example of erroneous code:

enum Foo { FirstValue };

let u = Foo::FirstValue { value: 0i32 }; // error: Foo::FirstValue
                                         // isn't a structure!
// or even simpler, if the structure wasn't defined at all:
let u = RandomName { random_field: 0i32 }; // error: RandomName
                                           // isn't a structure!

To fix this, please check: * Did you spell it right? * Did you accidentaly used an enum as a struct? * Did you accidentaly make an enum when you intended to use a struct?

Here is the previous code with all missing information:

struct Inner {
    value: i32
}

enum Foo {
    FirstValue(Inner)
}

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

    let t = Inner { value: 0i32 };
}

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, illegal recursive struct type
struct ListNode {
    head: u8,
    tail: Option<ListNode>,
}

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

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

E0073

You cannot define a struct (or enum) Foo that requires an instance of Foo in order to make a new Foo value. This is because there would be no way a first instance of Foo could be made to initialize another instance!

Here's an example of a struct that has this problem:

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

One fix is to use Option, like so:

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

Now it's possible to create at least one instance of Foo: Foo { x: None }.

E0079

Enum variants which contain no data can be given a custom integer representation. This error indicates that the value provided is not an integer literal and is therefore invalid.

E0080

This error indicates that the compiler was unable to sensibly evaluate an integer expression provided as an enum discriminant. 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)
}

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.

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

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

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

enum Bad {
    X,
    Y = 0
}

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

E0082

The default type for enum discriminants is isize, but it can be adjusted by adding the repr attribute to the enum declaration. This error indicates that an integer literal given as a discriminant is not a member of the discriminant type. For example:

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

Here, 1024 lies outside the valid range for u8, so the discriminant for A is invalid. You may want to change representation types to fix this, or else change invalid discriminant values so that they fit within the existing type.

Note also that without a representation manually defined, the compiler will optimize by using the smallest integer type possible.

E0083

At present, it's not possible to define a custom representation for an enum with a single variant. As a workaround you can add a Dummy variant.

See: https://github.com/rust-lang/rust/issues/10292

E0084

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:

enum Empty {}

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
}

The number of supplied parameters much 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
}

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

fn f() {}

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

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

struct Foo {
    value: String
}

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

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

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

E0089

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
}

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

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 unused

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

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

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
}

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

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

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

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
}

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

#![feature(intrinsics)]

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

E0101

You hit this error because the compiler the compiler lacks information to determine a type for this expression. Erroneous code example:

fn main() {
    let x = |_| {}; // error: cannot determine a type for this expression
}

You have two possibilities to solve this situation: * Give an explicit definition of the expression * Infer the expression

Examples:

fn main() {
    let x = |_ : u32| {}; // ok!
    // or:
    let x = |_| {};
    x(0u32);
}

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

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

Lifetime elision is a special, limited kind of inference for lifetimes in function signatures which allows you to leave out lifetimes in certain cases. For more background on lifetime elision see the book.

The lifetime elision rules require that any function signature with an elided output lifetime must either have

• exactly one input lifetime
• or, multiple input lifetimes, but the function must also be a method with a &self or &mut self receiver

In the first case, the output lifetime is inferred to be the same as the unique input lifetime. In the second case, the lifetime is instead inferred to be the same as the lifetime on &self or &mut self.

Here are some examples of elision errors:

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

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

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

E0107

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

Some basic examples include:

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

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

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 { } // error: expected 1, found 0

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

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 type

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

type X = u32; // ok!

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 type

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

type X = u32; // ok!

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

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 above

E0117

You got this error because because you tried to implement a foreign trait for a foreign type (with maybe a foreign type parameter). Erroneous code example:

impl Drop for u32 {}

The type, trait or the type parameter (or all of them) has to be defined in your crate. Example:

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
}

trait Bar { // or define your trait in your crate
    fn get(&self) -> usize;
}

impl Bar for u32 { // and then you implement it on a foreign type
    fn get(&self) -> usize { 0 }
}

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

E0119

There are conflicting trait implementations for the same type. Erroneous code example:

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

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

struct Foo {
    value: usize
}

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

When you write:

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

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

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

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

struct Foo;

fn main() {
    let f = Foo;

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

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 instead

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
}

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

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

E0128

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

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

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

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

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
}

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

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

extern {
    fn foo(s: SomeStruct); // ok!
}
// or
extern {
    fn foo(a: (u32, u32)); // ok!
}

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

E0132

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:

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

E0133

Using unsafe functionality, such as dereferencing raw pointers and calling functions via FFI or marked as unsafe, is potentially dangerous and disallowed by safety checks. 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(); }
}

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

E0137

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.

E0152

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:

#![feature(no_std)]
#![no_std]

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

E0154

Imports (use statements) are not allowed after non-item statements, such as variable declarations and expression statements.

Here is an example that demonstrates the error:

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

The solution is to declare the imports at the top of the block, function, or file.

Here is the previous example again, with the correct order:

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

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

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

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

E0159

You tried to use a trait as a struct constructor. Erroneous code example:

trait TraitNotAStruct {}

TraitNotAStruct{ value: 0 }; // error: use of trait `TraitNotAStruct` as a
                             //        struct constructor

Please verify you used the correct type name or please implement the trait on a struct and use this struct constructor. Example:

trait TraitNotAStruct {}

struct Foo {
    value: i32
}

Foo{ value: 0 }; // ok!

E0161

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.

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.
    foo(x);
}

// Try this instead:
let Irrefutable(x) = irr;
foo(x);

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

// Try this instead:
loop {
    let Irrefutable(x) = irr;
    ...
}

E0166

This error means that the compiler found a return expression in a function marked as diverging. A function diverges if it has ! in the place of the return type in its signature. For example:

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

For a function that diverges, every control path in the function must never return, for example with a loop that never breaks or a call to another diverging function (such as panic!()).

E0170

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

enum Method {
    GET,
    POST
}

you would match it using:

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

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

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

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

E0172

This error means that an attempt was made to specify the type of a variable with a combination of a concrete type and a trait. Consider the following example:

fn foo(bar: i32+std::fmt::Display) {}

The code is trying to specify that we want to receive a signed 32-bit integer which also implements Display. This doesn't make sense: when we pass i32, a concrete type, it implicitly includes all of the traits that it implements. This includes Display, Debug, Clone, and a host of others.

If i32 implements the trait we desire, there's no need to specify the trait separately. If it does not, then we need to impl the trait for i32 before passing it into foo. Either way, a fixed definition for foo will look like the following:

fn foo(bar: i32) {}

To learn more about traits, take a look at the Book:

https://doc.rust-lang.org/book/traits.html

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

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

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

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 specified

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!

E0192

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

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

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

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

struct Foo;

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

E0197

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

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.

struct Foo;

// unsafe is unnecessary
unsafe impl !Clone for Foo { }
// this will compile
impl !Clone for Foo { }

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

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

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

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

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

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

E0205

An attempt to implement the Copy trait for an enum failed because one of the variants does not implement Copy. To fix this, you must implement Copy for the mentioned variant. Note that this may not be possible, as in the example of

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

impl Copy for Foo { }

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

Here's another example that will fail:

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

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

E0206

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

E0207

You declared an unused type parameter when implementing a trait on an object. Erroneous code example:

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

struct Foo;

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

Please check your object definition and remove unused type parameter(s). Example:

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

struct Foo;

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

E0211

You used an intrinsic function which doesn't correspond to its definition. Erroneous code example:

#![feature(intrinsics)]

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

Please check the function definition. Example:

#![feature(intrinsics)]

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

E0220

You used an associated type which isn't defined in the trait. Erroneous code example:

trait Trait {
    type Bar;
}

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

Please verify you used the right trait or you didn't misspell the associated type name. Example:

trait Trait {
    type Bar;
}

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

E0232

The attribute must have a value. Erroneous code example:

#[rustc_on_unimplemented] // error: this attribute must have a value
trait Bar {}

Please supply the missing value of the attribute. Example:

#[rustc_on_unimplemented = "foo"] // ok!
trait Bar {}

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 }

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

E0249

This error indicates a constant expression for the array length was found, but it was not an integer (signed or unsigned) expression.

Some examples of code that produces this error are:

const A: [u32; "hello"] = []; // error
const B: [u32; true] = []; // error
const C: [u32; 0.0] = []; // error

E0250

There was an error while evaluating the expression for the length of a fixed- size array type.

Some examples of this error are:

// divide by zero in the length expression
const A: [u32; 1/0] = [];

// Rust currently will not evaluate the function `foo` at compile time
fn foo() -> usize { 12 }
const B: [u32; foo()] = [];

// it is an error to try to add `u8` and `f64`
use std::{f64, u8};
const C: [u32; u8::MAX + f64::EPSILON] = [];

E0251

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

An example of this error:

use foo::baz;
use bar::*; // error, do `use foo::baz as quux` instead on the previous line

fn main() {}

mod foo {
    pub struct baz;
}

mod bar {
    pub mod baz {}
}

E0252

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

An example of this error:

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

E0253

Attempt was made to import an unimportable value. This can happen when trying to import a method from a trait. An example of this error:

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

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

E0255

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

An example of this error:

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

fn foo() {}

mod bar {
     pub fn foo() {}
}

fn main() {}

E0256

You can't import a type or module when the name of the item being imported is the same as another type or submodule defined in the module.

An example of this error:

use foo::Bar; // error

type Bar = u32;

mod foo {
    pub mod Bar { }
}

fn main() {}

E0259

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

Wrong example:

extern crate a;
extern crate crate_a as a;

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 a;
extern crate crate_a as other_name;

E0260

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

For instance,

extern crate abc;

struct abc;

There are two possible solutions:

Solution #1: Rename the item.

extern crate abc;

struct xyz;

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

extern crate abc as xyz;

struct abc;

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

http://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,
}

These can be fixed by declaring lifetime parameters:

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

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

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, illegal lifetime parameter name `'static`
fn foo<'static>(x: &'static str) { }

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

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;

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

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 closure

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

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

w();

E0268

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
}

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

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

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

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.

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

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,I `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.

    }
}

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

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 `Foo` is not implemented for the
                     //     type `i32`
}

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

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

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

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

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

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

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

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

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> {
    // Some fields omitted.
}

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

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

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.

E0296

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

#![recursion_limit="1000"]

E0297

Patterns used to bind names must be irrefutable. That is, they must guarantee that a name will be extracted in all cases. Instead of pattern matching the loop variable, consider using a match or if let inside the loop body. For instance:

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

// Match inside the loop instead:
for item in xs {
    match item {
        Some(x) => ...
        None => ...
    }
}

// Or use `if let`:
for item in xs {
    if let Some(x) = item {
        ...
    }
}

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

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

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(ref s) => ...
    None => ...
}

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

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

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

E0306

In an array literal [x; N], N is the number of elements in the array. This number cannot be negative.

E0307

The length of an array is part of its type. For this reason, this length must be a compile-time constant.

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`

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
}

// This will compile, because it has the constraint on the type parameter
struct Foo<'a, T: 'a> {
    foo: &'a T
}

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
}

// This will compile, because it has the constraint on the type parameter
struct Foo<T: 'static> {
    foo: &'static T
}

E0317

User-defined types or type parameters cannot shadow the primitive types. This error indicates you tried to define a type, struct or enum with the same name as an existing primitive type.

See the Types section of the reference for more information about the primitive types:

http://doc.rust-lang.org/reference.html#types

E0318

Default impls for a trait must be located in the same crate where the trait was defined. For more information see the opt-in builtin traits RFC.

E0322

The Sized trait is a special trait built-in to the compiler for types with a constant size known at compile-time. This trait is automatically implemented for types as needed by the compiler, and it is currently disallowed to explicitly implement it for a type.

E0326

The types of any associated constants in a trait implementation must match the types in the trait definition. This error indicates that there was a mismatch.

Here's an example of this error:

trait Foo {
    const BAR: bool;
}

struct Bar;

impl Foo for Bar {
    const BAR: u32 = 5; // error, expected bool, found u32
}

E0327

You cannot use associated items other than constant items as patterns. This includes method items. Example of erroneous code:

enum B {}

impl B {
    fn bb() -> i32 { 0 }
}

fn main() {
    match 0 {
        B::bb => {} // error: associated items in match patterns must
                    // be constants
    }
}

Please check that you're not using a method as a pattern. Example:

enum B {
    ba,
    bb
}

fn main() {
    match B::ba {
        B::bb => {} // ok!
        _ => {}
    }
}

E0364

Private items cannot be publicly re-exported. This error indicates that you attempted to pub use a type or value that was not itself public.

Here is an example that demonstrates the error:

mod foo {
    const X: u32 = 1;
}
pub use foo::X;

The solution to this problem is to ensure that the items that you are re-exporting are themselves marked with pub:

mod foo {
    pub const X: u32 = 1;
}
pub use foo::X;

See the 'Use Declarations' section of the reference for more information on this topic:

http://doc.rust-lang.org/reference.html#use-declarations

E0365

Private modules cannot be publicly re-exported. This error indicates that you attempted to pub use a module that was not itself public.

Here is an example that demonstrates the error:

mod foo {
    pub const X: u32 = 1;
}
pub use foo as foo2;

The solution to this problem is to ensure that the module that you are re-exporting is itself marked with pub:

pub mod foo {
    pub const X: u32 = 1;
}
pub use foo as foo2;

See the 'Use Declarations' section of the reference for more information on this topic:

http://doc.rust-lang.org/reference.html#use-declarations

E0368

This error indicates that a binary assignment operator like += or ^= was applied to the wrong types. For example:

let mut x: u16 = 5;
x ^= true; // error, `^=` cannot be applied to types `u16` and `bool`
x += ();   // error, `+=` cannot be applied to types `u16` and `()`

Another problem you might be facing is this: suppose you've overloaded the + operator for some type Foo by implementing the std::ops::Add trait for Foo, but you find that using += does not work, as in this example:

use std::ops::Add;

struct Foo(u32);

impl Add for Foo {
    type Output = Foo;

    fn add(self, rhs: Foo) -> Foo {
        Foo(self.0 + rhs.0)
    }
}

fn main() {
    let mut x: Foo = Foo(5);
    x += Foo(7); // error, `+= cannot be applied to types `Foo` and `Foo`
}

This is because the binary assignment operators currently do not work off of traits, so it is not possible to overload them. See RFC 953 for a proposal to change this.

E0371

When Trait2 is a subtrait of Trait1 (for example, when Trait2 has a definition like trait Trait2: Trait1 { ... }), it is not allowed to implement Trait1 for Trait2. This is because Trait2 already implements Trait1 by definition, so it is not useful to do this.

Example:

trait Foo { fn foo(&self) { } }
trait Bar: Foo { }
trait Baz: Bar { }

impl Bar for Baz { } // error, `Baz` implements `Bar` by definition
impl Foo for Baz { } // error, `Baz` implements `Bar` which implements `Foo`
impl Baz for Baz { } // error, `Baz` (trivially) implements `Baz`
impl Baz for Bar { } // Note: This is OK

E0372

Trying to implement a trait for a trait object (as in impl Trait1 for Trait2 { ... }) does not work if the trait is not object-safe. Please see the RFC 255 for more details on object safety rules.

E0378

Method calls that aren't calls to inherent const methods are disallowed in statics, constants, and constant functions.

For example:

const BAZ: i32 = Foo(25).bar(); // error, `bar` isn't `const`

struct Foo(i32);

impl Foo {
    const fn foo(&self) -> i32 {
        self.bar() // error, `bar` isn't `const`
    }

    fn bar(&self) -> i32 { self.0 }
}

For more information about const fn's, see RFC 911.

E0379

Trait methods cannot be declared const by design. For more information, see RFC 911.

E0380

Default impls are only allowed for traits with no methods or associated items. For more information see the opt-in builtin traits RFC.

E0381

It is not allowed to use or capture an uninitialized variable. For example:

fn main() {
    let x: i32;
    let y = x; // error, use of possibly uninitialized variable

To fix this, ensure that any declared variables are initialized before being used.

E0392

This error indicates that a type or lifetime parameter has been declared but not actually used. Here is an example that demonstrates the error:

enum Foo<T> {
    Bar
}

If the type parameter was included by mistake, this error can be fixed by simply removing the type parameter, as shown below:

enum Foo {
    Bar
}

Alternatively, if the type parameter was intentionally inserted, it must be used. A simple fix is shown below:

enum Foo<T> {
    Bar(T)
}

This error may also commonly be found when working with unsafe code. For example, when using raw pointers one may wish to specify the lifetime for which the pointed-at data is valid. An initial attempt (below) causes this error:

struct Foo<'a, T> {
    x: *const T
}

We want to express the constraint that Foo should not outlive 'a, because the data pointed to by T is only valid for that lifetime. The problem is that there are no actual uses of 'a. It's possible to work around this by adding a PhantomData type to the struct, using it to tell the compiler to act as if the struct contained a borrowed reference &'a T:

use std::marker::PhantomData;

struct Foo<'a, T: 'a> {
    x: *const T,
    phantom: PhantomData<&'a T>
}

PhantomData can also be used to express information about unused type parameters. You can read more about it in the API documentation:

https://doc.rust-lang.org/std/marker/struct.PhantomData.html

E0394

From RFC 246:

It is illegal for a static to reference another static by value. It is required that all references be borrowed.

E0395

The value assigned to a constant expression must be known at compile time, which is not the case when comparing raw pointers. Erroneous code example:

static foo: i32 = 42;
static bar: i32 = 43;

static baz: bool = { (&foo as *const i32) == (&bar as *const i32) };
// error: raw pointers cannot be compared in statics!

Please check that the result of the comparison can be determined at compile time or isn't assigned to a constant expression. Example:

static foo: i32 = 42;
static bar: i32 = 43;

let baz: bool = { (&foo as *const i32) == (&bar as *const i32) };
// baz isn't a constant expression so it's ok

E0396

The value assigned to a constant expression must be known at compile time, which is not the case when dereferencing raw pointers. Erroneous code example:

const foo: i32 = 42;
const baz: *const i32 = (&foo as *const i32);

const deref: i32 = *baz;
// error: raw pointers cannot be dereferenced in constants

To fix this error, please do not assign this value to a constant expression. Example:

const foo: i32 = 42;
const baz: *const i32 = (&foo as *const i32);

unsafe { let deref: i32 = *baz; }
// baz isn't a constant expression so it's ok

You'll also note that this assignment must be done in an unsafe block!

E0397

It is not allowed for a mutable static to allocate or have destructors. For example:

// error: mutable statics are not allowed to have boxes
static mut FOO: Option<Box<usize>> = None;

// error: mutable statics are not allowed to have destructors
static mut BAR: Option<Vec<i32>> = None;

fn foo(arg: &Box<SomeTrait>) { ... }

fn foo<'a>(arg: &Box<SomeTrait+'a>) { ... }

E0403

Some type parameters have the same name. Example of erroneous code:

fn foo<T, T>(s: T, u: T) {} // error: the name `T` is already used for a type
                            //        parameter in this type parameter list

Please verify that none of the type parameterss are misspelled, and rename any clashing parameters. Example:

fn foo<T, Y>(s: T, u: Y) {} // ok!

E0404

You tried to implement something which was not a trait on an object. Example of erroneous code:

struct Foo;
struct Bar;

impl Foo for Bar {} // error: `Foo` is not a trait

Please verify that you didn't misspell the trait's name or otherwise use the wrong identifier. Example:

trait Foo {
    // some functions
}
struct Bar;

impl Foo for Bar { // ok!
    // functions implementation
}

E0405

An unknown trait was implemented. Example of erroneous code:

struct Foo;

impl SomeTrait for Foo {} // error: use of undeclared trait name `SomeTrait`

Please verify that the name of the trait wasn't misspelled and ensure that it was imported. Example:

// solution 1:
use some_file::SomeTrait;

// solution 2:
trait SomeTrait {
    // some functions
}

struct Foo;

impl SomeTrait for Foo { // ok!
    // implements functions
}

E0407

A definition of a method not in the implemented trait was given in a trait implementation. Example of erroneous code:

trait Foo {
    fn a();
}

struct Bar;

impl Foo for Bar {
    fn a() {}
    fn b() {} // error: method `b` is not a member of trait `Foo`
}

Please verify you didn't misspell the method name and you used the correct trait. First example:

trait Foo {
    fn a();
    fn b();
}

struct Bar;

impl Foo for Bar {
    fn a() {}
    fn b() {} // ok!
}

Second example:

trait Foo {
    fn a();
}

struct Bar;

impl Foo for Bar {
    fn a() {}
}

impl Bar {
    fn b() {}
}

E0428

A type or module has been defined more than once. Example of erroneous code:

struct Bar;
struct Bar; // error: duplicate definition of value `Bar`

Please verify you didn't misspell the type/module's name or remove/rename the duplicated one. Example:

struct Bar;
struct Bar2; // ok!

E0433

Invalid import. Example of erroneous code:

use something_which_doesnt_exist;
// error: unresolved import `something_which_doesnt_exist`

Please verify you didn't misspell the import's name.