rustc_typeck::DIAGNOSTICS

pub const DIAGNOSTICS: [(&'static str, &'static str); 131usize] = [("E0045",
  "\nRust only supports variadic parameters for interoperability with C code in its\nFFI. As such, variadic parameters can only be used with functions which are\nusing the C ABI. Examples of erroneous code:\n\n```compile_fail\nextern \"rust-call\" { fn foo(x: u8, ...); }\n\n// or\n\nfn foo(x: u8, ...) {}\n```\n\nTo fix such code, put them in an extern \"C\" block:\n\n```ignore\nextern \"C\" fn foo(x: u8, ...);\n```\n\nOr:\n\n```\nextern \"C\" {\n    fn foo (x: u8, ...);\n}\n```\n"),
 ("E0211",
  "\nYou used a function or type which doesn\'t fit the requirements for where it was\nused. Erroneous code examples:\n\n```compile_fail\n#![feature(intrinsics)]\n\nextern \"rust-intrinsic\" {\n    fn size_of<T>(); // error: intrinsic has wrong type\n}\n\n// or:\n\nfn main() -> i32 { 0 }\n// error: main function expects type: `fn() {main}`: expected (), found i32\n\n// or:\n\nlet x = 1u8;\nmatch x {\n    0u8...3i8 => (),\n    // error: mismatched types in range: expected u8, found i8\n    _ => ()\n}\n\n// or:\n\nuse std::rc::Rc;\nstruct Foo;\n\nimpl Foo {\n    fn x(self: Rc<Foo>) {}\n    // error: mismatched self type: expected `Foo`: expected struct\n    //        `Foo`, found struct `alloc::rc::Rc`\n}\n```\n\nFor the first code example, please check the function definition. Example:\n\n```\n#![feature(intrinsics)]\n\nextern \"rust-intrinsic\" {\n    fn size_of<T>() -> usize; // ok!\n}\n```\n\nThe second case example is a bit particular : the main function must always\nhave this definition:\n\n```compile_fail\nfn main();\n```\n\nThey never take parameters and never return types.\n\nFor the third example, when you match, all patterns must have the same type\nas the type you\'re matching on. Example:\n\n```\nlet x = 1u8;\n\nmatch x {\n    0u8...3u8 => (), // ok!\n    _ => ()\n}\n```\n\nAnd finally, for the last example, only `Box<Self>`, `&Self`, `Self`,\nor `&mut Self` work as explicit self parameters. Example:\n\n```\nstruct Foo;\n\nimpl Foo {\n    fn x(self: Box<Foo>) {} // ok!\n}\n```\n"),
 ("E0131",
  "\nIt is not possible to define `main` with type parameters, or even with function\nparameters. When `main` is present, it must take no arguments and return `()`.\nErroneous code example:\n\n```compile_fail\nfn main<T>() { // error: main function is not allowed to have type parameters\n}\n```\n"),
 ("E0132",
  "\nIt is not possible to declare type parameters on a function that has the `start`\nattribute. Such a function must have the following type signature:\n\n```ignore\nfn(isize, *const *const u8) -> isize;\n```\n"),
 ("E0023",
  "\nA pattern used to match against an enum variant must provide a sub-pattern for\neach field of the enum variant. This error indicates that a pattern attempted to\nextract an incorrect number of fields from a variant.\n\n```\nenum Fruit {\n    Apple(String, String),\n    Pear(u32),\n}\n```\n\nHere the `Apple` variant has two fields, and should be matched against like so:\n\n```\nenum Fruit {\n    Apple(String, String),\n    Pear(u32),\n}\n\nlet x = Fruit::Apple(String::new(), String::new());\n\n// Correct.\nmatch x {\n    Fruit::Apple(a, b) => {},\n    _ => {}\n}\n```\n\nMatching with the wrong number of fields has no sensible interpretation:\n\n```compile_fail\nenum Fruit {\n    Apple(String, String),\n    Pear(u32),\n}\n\nlet x = Fruit::Apple(String::new(), String::new());\n\n// Incorrect.\nmatch x {\n    Fruit::Apple(a) => {},\n    Fruit::Apple(a, b, c) => {},\n}\n```\n\nCheck how many fields the enum was declared with and ensure that your pattern\nuses the same number.\n"),
 ("E0024",
  "\nThis error indicates that a pattern attempted to extract the fields of an enum\nvariant with no fields. Here\'s a tiny example of this error:\n\n```compile_fail\n// This enum has two variants.\nenum Number {\n    // This variant has no fields.\n    Zero,\n    // This variant has one field.\n    One(u32)\n}\n\n// Assuming x is a Number we can pattern match on its contents.\nmatch x {\n    Number::Zero(inside) => {},\n    Number::One(inside) => {},\n}\n```\n\nThe pattern match `Zero(inside)` is incorrect because the `Zero` variant\ncontains no fields, yet the `inside` name attempts to bind the first field of\nthe enum.\n"),
 ("E0025",
  "\nEach field of a struct can only be bound once in a pattern. Erroneous code\nexample:\n\n```compile_fail\nstruct Foo {\n    a: u8,\n    b: u8,\n}\n\nfn main(){\n    let x = Foo { a:1, b:2 };\n\n    let Foo { a: x, a: y } = x;\n    // error: field `a` bound multiple times in the pattern\n}\n```\n\nEach occurrence of a field name binds the value of that field, so to fix this\nerror you will have to remove or alter the duplicate uses of the field name.\nPerhaps you misspelled another field name? Example:\n\n```\nstruct Foo {\n    a: u8,\n    b: u8,\n}\n\nfn main(){\n    let x = Foo { a:1, b:2 };\n\n    let Foo { a: x, b: y } = x; // ok!\n}\n```\n"),
 ("E0026",
  "\nThis error indicates that a struct pattern attempted to extract a non-existent\nfield from a struct. Struct fields are identified by the name used before the\ncolon `:` so struct patterns should resemble the declaration of the struct type\nbeing matched.\n\n```\n// Correct matching.\nstruct Thing {\n    x: u32,\n    y: u32\n}\n\nlet thing = Thing { x: 1, y: 2 };\n\nmatch thing {\n    Thing { x: xfield, y: yfield } => {}\n}\n```\n\nIf you are using shorthand field patterns but want to refer to the struct field\nby a different name, you should rename it explicitly.\n\nChange this:\n\n```compile_fail\nstruct Thing {\n    x: u32,\n    y: u32\n}\n\nlet thing = Thing { x: 0, y: 0 };\n\nmatch thing {\n    Thing { x, z } => {}\n}\n```\n\nTo this:\n\n```\nstruct Thing {\n    x: u32,\n    y: u32\n}\n\nlet thing = Thing { x: 0, y: 0 };\n\nmatch thing {\n    Thing { x, y: z } => {}\n}\n```\n"),
 ("E0027",
  "\nThis error indicates that a pattern for a struct fails to specify a sub-pattern\nfor every one of the struct\'s fields. Ensure that each field from the struct\'s\ndefinition is mentioned in the pattern, or use `..` to ignore unwanted fields.\n\nFor example:\n\n```compile_fail\nstruct Dog {\n    name: String,\n    age: u32,\n}\n\nlet d = Dog { name: \"Rusty\".to_string(), age: 8 };\n\n// This is incorrect.\nmatch d {\n    Dog { age: x } => {}\n}\n```\n\nThis is correct (explicit):\n\n```\nstruct Dog {\n    name: String,\n    age: u32,\n}\n\nlet d = Dog { name: \"Rusty\".to_string(), age: 8 };\n\nmatch d {\n    Dog { name: ref n, age: x } => {}\n}\n\n// This is also correct (ignore unused fields).\nmatch d {\n    Dog { age: x, .. } => {}\n}\n```\n"),
 ("E0029",
  "\nIn a match expression, only numbers and characters can be matched against a\nrange. This is because the compiler checks that the range is non-empty at\ncompile-time, and is unable to evaluate arbitrary comparison functions. If you\nwant to capture values of an orderable type between two end-points, you can use\na guard.\n\n```compile_fail\n// The ordering relation for strings can\'t be evaluated at compile time,\n// so this doesn\'t work:\nmatch string {\n    \"hello\" ... \"world\" => {}\n    _ => {}\n}\n\n// This is a more general version, using a guard:\nmatch string {\n    s if s >= \"hello\" && s <= \"world\" => {}\n    _ => {}\n}\n```\n"),
 ("E0033",
  "\nThis error indicates that a pointer to a trait type cannot be implicitly\ndereferenced by a pattern. Every trait defines a type, but because the\nsize of trait implementors isn\'t fixed, this type has no compile-time size.\nTherefore, all accesses to trait types must be through pointers. If you\nencounter this error you should try to avoid dereferencing the pointer.\n\n```ignore\nlet trait_obj: &SomeTrait = ...;\n\n// This tries to implicitly dereference to create an unsized local variable.\nlet &invalid = trait_obj;\n\n// You can call methods without binding to the value being pointed at.\ntrait_obj.method_one();\ntrait_obj.method_two();\n```\n\nYou can read more about trait objects in the Trait Object section of the\nReference:\n\nhttps://doc.rust-lang.org/reference.html#trait-objects\n"),
 ("E0034",
  "\nThe compiler doesn\'t know what method to call because more than one method\nhas the same prototype. Erroneous code example:\n\n```compile_fail\nstruct Test;\n\ntrait Trait1 {\n    fn foo();\n}\n\ntrait Trait2 {\n    fn foo();\n}\n\nimpl Trait1 for Test { fn foo() {} }\nimpl Trait2 for Test { fn foo() {} }\n\nfn main() {\n    Test::foo() // error, which foo() to call?\n}\n```\n\nTo avoid this error, you have to keep only one of them and remove the others.\nSo let\'s take our example and fix it:\n\n```\nstruct Test;\n\ntrait Trait1 {\n    fn foo();\n}\n\nimpl Trait1 for Test { fn foo() {} }\n\nfn main() {\n    Test::foo() // and now that\'s good!\n}\n```\n\nHowever, a better solution would be using fully explicit naming of type and\ntrait:\n\n```\nstruct Test;\n\ntrait Trait1 {\n    fn foo();\n}\n\ntrait Trait2 {\n    fn foo();\n}\n\nimpl Trait1 for Test { fn foo() {} }\nimpl Trait2 for Test { fn foo() {} }\n\nfn main() {\n    <Test as Trait1>::foo()\n}\n```\n\nOne last example:\n\n```\ntrait F {\n    fn m(&self);\n}\n\ntrait G {\n    fn m(&self);\n}\n\nstruct X;\n\nimpl F for X { fn m(&self) { println!(\"I am F\"); } }\nimpl G for X { fn m(&self) { println!(\"I am G\"); } }\n\nfn main() {\n    let f = X;\n\n    F::m(&f); // it displays \"I am F\"\n    G::m(&f); // it displays \"I am G\"\n}\n```\n"),
 ("E0035",
  "\nYou tried to give a type parameter where it wasn\'t needed. Erroneous code\nexample:\n\n```compile_fail\nstruct Test;\n\nimpl Test {\n    fn method(&self) {}\n}\n\nfn main() {\n    let x = Test;\n\n    x.method::<i32>(); // Error: Test::method doesn\'t need type parameter!\n}\n```\n\nTo fix this error, just remove the type parameter:\n\n```\nstruct Test;\n\nimpl Test {\n    fn method(&self) {}\n}\n\nfn main() {\n    let x = Test;\n\n    x.method(); // OK, we\'re good!\n}\n```\n"),
 ("E0036",
  "\nThis error occurrs when you pass too many or not enough type parameters to\na method. Erroneous code example:\n\n```compile_fail\nstruct Test;\n\nimpl Test {\n    fn method<T>(&self, v: &[T]) -> usize {\n        v.len()\n    }\n}\n\nfn main() {\n    let x = Test;\n    let v = &[0];\n\n    x.method::<i32, i32>(v); // error: only one type parameter is expected!\n}\n```\n\nTo fix it, just specify a correct number of type parameters:\n\n```\nstruct Test;\n\nimpl Test {\n    fn method<T>(&self, v: &[T]) -> usize {\n        v.len()\n    }\n}\n\nfn main() {\n    let x = Test;\n    let v = &[0];\n\n    x.method::<i32>(v); // OK, we\'re good!\n}\n```\n\nPlease note on the last example that we could have called `method` like this:\n\n```ignore\nx.method(v);\n```\n"),
 ("E0040",
  "\nIt is not allowed to manually call destructors in Rust. It is also not\nnecessary to do this since `drop` is called automatically whenever a value goes\nout of scope.\n\nHere\'s an example of this error:\n\n```compile_fail\nstruct Foo {\n    x: i32,\n}\n\nimpl Drop for Foo {\n    fn drop(&mut self) {\n        println!(\"kaboom\");\n    }\n}\n\nfn main() {\n    let mut x = Foo { x: -7 };\n    x.drop(); // error: explicit use of destructor method\n}\n```\n"),
 ("E0044",
  "\nYou can\'t use type parameters on foreign items. Example of erroneous code:\n\n```compile_fail\nextern { fn some_func<T>(x: T); }\n```\n\nTo fix this, replace the type parameter with the specializations that you\nneed:\n\n```\nextern { fn some_func_i32(x: i32); }\nextern { fn some_func_i64(x: i64); }\n```\n"),
 ("E0046",
  "\nItems are missing in a trait implementation. Erroneous code example:\n\n```compile_fail\ntrait Foo {\n    fn foo();\n}\n\nstruct Bar;\n\nimpl Foo for Bar {}\n// error: not all trait items implemented, missing: `foo`\n```\n\nWhen trying to make some type implement a trait `Foo`, you must, at minimum,\nprovide implementations for all of `Foo`\'s required methods (meaning the\nmethods that do not have default implementations), as well as any required\ntrait items like associated types or constants. Example:\n\n```\ntrait Foo {\n    fn foo();\n}\n\nstruct Bar;\n\nimpl Foo for Bar {\n    fn foo() {} // ok!\n}\n```\n"),
 ("E0049",
  "\nThis error indicates that an attempted implementation of a trait method\nhas the wrong number of type parameters.\n\nFor example, the trait below has a method `foo` with a type parameter `T`,\nbut the implementation of `foo` for the type `Bar` is missing this parameter:\n\n```compile_fail\ntrait Foo {\n    fn foo<T: Default>(x: T) -> Self;\n}\n\nstruct Bar;\n\n// error: method `foo` has 0 type parameters but its trait declaration has 1\n// type parameter\nimpl Foo for Bar {\n    fn foo(x: bool) -> Self { Bar }\n}\n```\n"),
 ("E0050",
  "\nThis error indicates that an attempted implementation of a trait method\nhas the wrong number of function parameters.\n\nFor example, the trait below has a method `foo` with two function parameters\n(`&self` and `u8`), but the implementation of `foo` for the type `Bar` omits\nthe `u8` parameter:\n\n```compile_fail\ntrait Foo {\n    fn foo(&self, x: u8) -> bool;\n}\n\nstruct Bar;\n\n// error: method `foo` has 1 parameter but the declaration in trait `Foo::foo`\n// has 2\nimpl Foo for Bar {\n    fn foo(&self) -> bool { true }\n}\n```\n"),
 ("E0053",
  "\nThe parameters of any trait method must match between a trait implementation\nand the trait definition.\n\nHere are a couple examples of this error:\n\n```compile_fail\ntrait Foo {\n    fn foo(x: u16);\n    fn bar(&self);\n}\n\nstruct Bar;\n\nimpl Foo for Bar {\n    // error, expected u16, found i16\n    fn foo(x: i16) { }\n\n    // error, values differ in mutability\n    fn bar(&mut self) { }\n}\n```\n"),
 ("E0054",
  "\nIt is not allowed to cast to a bool. If you are trying to cast a numeric type\nto a bool, you can compare it with zero instead:\n\n```compile_fail\nlet x = 5;\n\n// Not allowed, won\'t compile\nlet x_is_nonzero = x as bool;\n```\n\n```\nlet x = 5;\n\n// Ok\nlet x_is_nonzero = x != 0;\n```\n"),
 ("E0055",
  "\nDuring a method call, a value is automatically dereferenced as many times as\nneeded to make the value\'s type match the method\'s receiver. The catch is that\nthe compiler will only attempt to dereference a number of times up to the\nrecursion limit (which can be set via the `recursion_limit` attribute).\n\nFor a somewhat artificial example:\n\n```compile_fail,ignore\n#![recursion_limit=\"2\"]\n\nstruct Foo;\n\nimpl Foo {\n    fn foo(&self) {}\n}\n\nfn main() {\n    let foo = Foo;\n    let ref_foo = &&Foo;\n\n    // error, reached the recursion limit while auto-dereferencing &&Foo\n    ref_foo.foo();\n}\n```\n\nOne fix may be to increase the recursion limit. Note that it is possible to\ncreate an infinite recursion of dereferencing, in which case the only fix is to\nsomehow break the recursion.\n"),
 ("E0057",
  "\nWhen invoking closures or other implementations of the function traits `Fn`,\n`FnMut` or `FnOnce` using call notation, the number of parameters passed to the\nfunction must match its definition.\n\nAn example using a closure:\n\n```compile_fail\nlet f = |x| x * 3;\nlet a = f();        // invalid, too few parameters\nlet b = f(4);       // this works!\nlet c = f(2, 3);    // invalid, too many parameters\n```\n\nA generic function must be treated similarly:\n\n```\nfn foo<F: Fn()>(f: F) {\n    f(); // this is valid, but f(3) would not work\n}\n```\n"),
 ("E0059",
  "\nThe built-in function traits are generic over a tuple of the function arguments.\nIf one uses angle-bracket notation (`Fn<(T,), Output=U>`) instead of parentheses\n(`Fn(T) -> U`) to denote the function trait, the type parameter should be a\ntuple. Otherwise function call notation cannot be used and the trait will not be\nimplemented by closures.\n\nThe most likely source of this error is using angle-bracket notation without\nwrapping the function argument type into a tuple, for example:\n\n```compile_fail\nfn foo<F: Fn<i32>>(f: F) -> F::Output { f(3) }\n```\n\nIt can be fixed by adjusting the trait bound like this:\n\n```ignore\nfn foo<F: Fn<(i32,)>>(f: F) -> F::Output { f(3) }\n```\n\nNote that `(T,)` always denotes the type of a 1-tuple containing an element of\ntype `T`. The comma is necessary for syntactic disambiguation.\n"),
 ("E0060",
  "\nExternal C functions are allowed to be variadic. However, a variadic function\ntakes a minimum number of arguments. For example, consider C\'s variadic `printf`\nfunction:\n\n```ignore\nextern crate libc;\nuse libc::{ c_char, c_int };\n\nextern \"C\" {\n    fn printf(_: *const c_char, ...) -> c_int;\n}\n```\n\nUsing this declaration, it must be called with at least one argument, so\nsimply calling `printf()` is invalid. But the following uses are allowed:\n\n```ignore\nunsafe {\n    use std::ffi::CString;\n\n    printf(CString::new(\"test\\n\").unwrap().as_ptr());\n    printf(CString::new(\"number = %d\\n\").unwrap().as_ptr(), 3);\n    printf(CString::new(\"%d, %d\\n\").unwrap().as_ptr(), 10, 5);\n}\n```\n"),
 ("E0061",
  "\nThe number of arguments passed to a function must match the number of arguments\nspecified in the function signature.\n\nFor example, a function like:\n\n```\nfn f(a: u16, b: &str) {}\n```\n\nMust always be called with exactly two arguments, e.g. `f(2, \"test\")`.\n\nNote that Rust does not have a notion of optional function arguments or\nvariadic functions (except for its C-FFI).\n"),
 ("E0062",
  "\nThis error indicates that during an attempt to build a struct or struct-like\nenum variant, one of the fields was specified more than once. Erroneous code\nexample:\n\n```compile_fail\nstruct Foo {\n    x: i32\n}\n\nfn main() {\n    let x = Foo {\n                x: 0,\n                x: 0, // error: field `x` specified more than once\n            };\n}\n```\n\nEach field should be specified exactly one time. Example:\n\n```\nstruct Foo {\n    x: i32\n}\n\nfn main() {\n    let x = Foo { x: 0 }; // ok!\n}\n```\n"),
 ("E0063",
  "\nThis error indicates that during an attempt to build a struct or struct-like\nenum variant, one of the fields was not provided. Erroneous code example:\n\n```compile_fail\nstruct Foo {\n    x: i32,\n    y: i32\n}\n\nfn main() {\n    let x = Foo { x: 0 }; // error: missing field: `y`\n}\n```\n\nEach field should be specified exactly once. Example:\n\n```\nstruct Foo {\n    x: i32,\n    y: i32\n}\n\nfn main() {\n    let x = Foo { x: 0, y: 0 }; // ok!\n}\n```\n"),
 ("E0066",
  "\nBox placement expressions (like C++\'s \"placement new\") do not yet support any\nplace expression except the exchange heap (i.e. `std::boxed::HEAP`).\nFurthermore, the syntax is changing to use `in` instead of `box`. See [RFC 470]\nand [RFC 809] for more details.\n\n[RFC 470]: https://github.com/rust-lang/rfcs/pull/470\n[RFC 809]: https://github.com/rust-lang/rfcs/pull/809\n"),
 ("E0067",
  "\nThe left-hand side of a compound assignment expression must be an lvalue\nexpression. An lvalue expression represents a memory location and includes\nitem paths (ie, namespaced variables), dereferences, indexing expressions,\nand field references.\n\nLet\'s start with some erroneous code examples:\n\n```compile_fail\nuse std::collections::LinkedList;\n\n// Bad: assignment to non-lvalue expression\nLinkedList::new() += 1;\n\n// ...\n\nfn some_func(i: &mut i32) {\n    i += 12; // Error : \'+=\' operation cannot be applied on a reference !\n}\n```\n\nAnd now some working examples:\n\n```\nlet mut i : i32 = 0;\n\ni += 12; // Good !\n\n// ...\n\nfn some_func(i: &mut i32) {\n    *i += 12; // Good !\n}\n```\n"),
 ("E0069",
  "\nThe compiler found a function whose body contains a `return;` statement but\nwhose return type is not `()`. An example of this is:\n\n```compile_fail\n// error\nfn foo() -> u8 {\n    return;\n}\n```\n\nSince `return;` is just like `return ();`, there is a mismatch between the\nfunction\'s return type and the value being returned.\n"),
 ("E0070",
  "\nThe left-hand side of an assignment operator must be an lvalue expression. An\nlvalue expression represents a memory location and can be a variable (with\noptional namespacing), a dereference, an indexing expression or a field\nreference.\n\nMore details can be found here:\nhttps://doc.rust-lang.org/reference.html#lvalues-rvalues-and-temporaries\n\nNow, we can go further. Here are some erroneous code examples:\n\n```compile_fail\nstruct SomeStruct {\n    x: i32,\n    y: i32\n}\n\nconst SOME_CONST : i32 = 12;\n\nfn some_other_func() {}\n\nfn some_function() {\n    SOME_CONST = 14; // error : a constant value cannot be changed!\n    1 = 3; // error : 1 isn\'t a valid lvalue!\n    some_other_func() = 4; // error : we can\'t assign value to a function!\n    SomeStruct.x = 12; // error : SomeStruct a structure name but it is used\n                       // like a variable!\n}\n```\n\nAnd now let\'s give working examples:\n\n```\nstruct SomeStruct {\n    x: i32,\n    y: i32\n}\nlet mut s = SomeStruct {x: 0, y: 0};\n\ns.x = 3; // that\'s good !\n\n// ...\n\nfn some_func(x: &mut i32) {\n    *x = 12; // that\'s good !\n}\n```\n"),
 ("E0071",
  "\nYou tried to use structure-literal syntax to create an item that is\nnot a struct-style structure or enum variant.\n\nExample of erroneous code:\n\n```compile_fail\nenum Foo { FirstValue(i32) };\n\nlet u = Foo::FirstValue { value: 0 }; // error: Foo::FirstValue\n                                         // isn\'t a structure!\n// or even simpler, if the name doesn\'t refer to a structure at all.\nlet t = u32 { value: 4 }; // error: `u32` does not name a structure.\n```\n\nTo fix this, ensure that the name was correctly spelled, and that\nthe correct form of initializer was used.\n\nFor example, the code above can be fixed to:\n\n```\nenum Foo {\n    FirstValue(i32)\n}\n\nfn main() {\n    let u = Foo::FirstValue(0i32);\n\n    let t = 4;\n}\n```\n"),
 ("E0073",
  "\nYou cannot define a struct (or enum) `Foo` that requires an instance of `Foo`\nin order to make a new `Foo` value. This is because there would be no way a\nfirst instance of `Foo` could be made to initialize another instance!\n\nHere\'s an example of a struct that has this problem:\n\n```compile_fail\nstruct Foo { x: Box<Foo> } // error\n```\n\nOne fix is to use `Option`, like so:\n\n```\nstruct Foo { x: Option<Box<Foo>> }\n```\n\nNow it\'s possible to create at least one instance of `Foo`: `Foo { x: None }`.\n"),
 ("E0074",
  "\nWhen using the `#[simd]` attribute on a tuple struct, the components of the\ntuple struct must all be of a concrete, nongeneric type so the compiler can\nreason about how to use SIMD with them. This error will occur if the types\nare generic.\n\nThis will cause an error:\n\n```compile_fail\n#![feature(simd)]\n\n#[simd]\nstruct Bad<T>(T, T, T);\n```\n\nThis will not:\n\n```\n#![feature(simd)]\n\n#[simd]\nstruct Good(u32, u32, u32);\n```\n"),
 ("E0075",
  "\nThe `#[simd]` attribute can only be applied to non empty tuple structs, because\nit doesn\'t make sense to try to use SIMD operations when there are no values to\noperate on.\n\nThis will cause an error:\n\n```compile_fail\n#![feature(repr_simd)]\n\n#[repr(simd)]\nstruct Bad;\n```\n\nThis will not:\n\n```\n#![feature(repr_simd)]\n\n#[repr(simd)]\nstruct Good(u32);\n```\n"),
 ("E0076",
  "\nWhen using the `#[simd]` attribute to automatically use SIMD operations in tuple\nstruct, the types in the struct must all be of the same type, or the compiler\nwill trigger this error.\n\nThis will cause an error:\n\n```compile_fail\n#![feature(simd)]\n\n#[simd]\nstruct Bad(u16, u32, u32);\n```\n\nThis will not:\n\n```\n#![feature(simd)]\n\n#[simd]\nstruct Good(u32, u32, u32);\n```\n"),
 ("E0077",
  "\nWhen using the `#[simd]` attribute on a tuple struct, the elements in the tuple\nmust be machine types so SIMD operations can be applied to them.\n\nThis will cause an error:\n\n```compile_fail\n#![feature(simd)]\n\n#[simd]\nstruct Bad(String);\n```\n\nThis will not:\n\n```\n#![feature(simd)]\n\n#[simd]\nstruct Good(u32, u32, u32);\n```\n"),
 ("E0079",
  "\nEnum variants which contain no data can be given a custom integer\nrepresentation. This error indicates that the value provided is not an integer\nliteral and is therefore invalid.\n\nFor example, in the following code:\n\n```compile_fail\nenum Foo {\n    Q = \"32\"\n}\n```\n\nWe try to set the representation to a string.\n\nThere\'s no general fix for this; if you can work with an integer then just set\nit to one:\n\n```\nenum Foo {\n    Q = 32\n}\n```\n\nHowever if you actually wanted a mapping between variants and non-integer\nobjects, it may be preferable to use a method with a match instead:\n\n```\nenum Foo { Q }\nimpl Foo {\n    fn get_str(&self) -> &\'static str {\n        match *self {\n            Foo::Q => \"32\",\n        }\n    }\n}\n```\n"),
 ("E0080",
  "\nThis error indicates that the compiler was unable to sensibly evaluate an\ninteger expression provided as an enum discriminant. Attempting to divide by 0\nor causing integer overflow are two ways to induce this error. For example:\n\n```compile_fail\nenum Enum {\n    X = (1 << 500),\n    Y = (1 / 0)\n}\n```\n\nEnsure that the expressions given can be evaluated as the desired integer type.\nSee the FFI section of the Reference for more information about using a custom\ninteger type:\n\nhttps://doc.rust-lang.org/reference.html#ffi-attributes\n"),
 ("E0081",
  "\nEnum discriminants are used to differentiate enum variants stored in memory.\nThis error indicates that the same value was used for two or more variants,\nmaking them impossible to tell apart.\n\n```compile_fail\n// Bad.\nenum Enum {\n    P = 3,\n    X = 3,\n    Y = 5\n}\n```\n\n```\n// Good.\nenum Enum {\n    P,\n    X = 3,\n    Y = 5\n}\n```\n\nNote that variants without a manually specified discriminant are numbered from\ntop to bottom starting from 0, so clashes can occur with seemingly unrelated\nvariants.\n\n```compile_fail\nenum Bad {\n    X,\n    Y = 0\n}\n```\n\nHere `X` will have already been specified the discriminant 0 by the time `Y` is\nencountered, so a conflict occurs.\n"),
 ("E0082",
  "\nWhen you specify enum discriminants with `=`, the compiler expects `isize`\nvalues by default. Or you can add the `repr` attibute to the enum declaration\nfor an explicit choice of the discriminant type. In either cases, the\ndiscriminant values must fall within a valid range for the expected type;\notherwise this error is raised. For example:\n\n```compile_fail\n#[repr(u8)]\nenum Thing {\n    A = 1024,\n    B = 5\n}\n```\n\nHere, 1024 lies outside the valid range for `u8`, so the discriminant for `A` is\ninvalid. Here is another, more subtle example which depends on target word size:\n\n```compile_fail\nenum DependsOnPointerSize {\n    A = 1 << 32\n}\n```\n\nHere, `1 << 32` is interpreted as an `isize` value. So it is invalid for 32 bit\ntarget (`target_pointer_width = \"32\"`) but valid for 64 bit target.\n\nYou may want to change representation types to fix this, or else change invalid\ndiscriminant values so that they fit within the existing type.\n"),
 ("E0084",
  "\nIt is impossible to define an integer type to be used to represent zero-variant\nenum values because there are no zero-variant enum values. There is no way to\nconstruct an instance of the following type using only safe code:\n\n```\nenum Empty {}\n```\n"),
 ("E0087",
  "\nToo many type parameters were supplied for a function. For example:\n\n```compile_fail\nfn foo<T>() {}\n\nfn main() {\n    foo::<f64, bool>(); // error, expected 1 parameter, found 2 parameters\n}\n```\n\nThe number of supplied parameters must exactly match the number of defined type\nparameters.\n"),
 ("E0088",
  "\nYou gave too many lifetime parameters. Erroneous code example:\n\n```compile_fail\nfn f() {}\n\nfn main() {\n    f::<\'static>() // error: too many lifetime parameters provided\n}\n```\n\nPlease check you give the right number of lifetime parameters. Example:\n\n```\nfn f() {}\n\nfn main() {\n    f() // ok!\n}\n```\n\nIt\'s also important to note that the Rust compiler can generally\ndetermine the lifetime by itself. Example:\n\n```\nstruct Foo {\n    value: String\n}\n\nimpl Foo {\n    // it can be written like this\n    fn get_value<\'a>(&\'a self) -> &\'a str { &self.value }\n    // but the compiler works fine with this too:\n    fn without_lifetime(&self) -> &str { &self.value }\n}\n\nfn main() {\n    let f = Foo { value: \"hello\".to_owned() };\n\n    println!(\"{}\", f.get_value());\n    println!(\"{}\", f.without_lifetime());\n}\n```\n"),
 ("E0089",
  "\nNot enough type parameters were supplied for a function. For example:\n\n```compile_fail\nfn foo<T, U>() {}\n\nfn main() {\n    foo::<f64>(); // error, expected 2 parameters, found 1 parameter\n}\n```\n\nNote that if a function takes multiple type parameters but you want the compiler\nto infer some of them, you can use type placeholders:\n\n```compile_fail\nfn foo<T, U>(x: T) {}\n\nfn main() {\n    let x: bool = true;\n    foo::<f64>(x);    // error, expected 2 parameters, found 1 parameter\n    foo::<_, f64>(x); // same as `foo::<bool, f64>(x)`\n}\n```\n"),
 ("E0091",
  "\nYou gave an unnecessary type parameter in a type alias. Erroneous code\nexample:\n\n```compile_fail\ntype Foo<T> = u32; // error: type parameter `T` is unused\n// or:\ntype Foo<A,B> = Box<A>; // error: type parameter `B` is unused\n```\n\nPlease check you didn\'t write too many type parameters. Example:\n\n```\ntype Foo = u32; // ok!\ntype Foo2<A> = Box<A>; // ok!\n```\n"),
 ("E0092",
  "\nYou tried to declare an undefined atomic operation function.\nErroneous code example:\n\n```compile_fail\n#![feature(intrinsics)]\n\nextern \"rust-intrinsic\" {\n    fn atomic_foo(); // error: unrecognized atomic operation\n                     //        function\n}\n```\n\nPlease check you didn\'t make a mistake in the function\'s name. All intrinsic\nfunctions are defined in librustc_trans/trans/intrinsic.rs and in\nlibcore/intrinsics.rs in the Rust source code. Example:\n\n```\n#![feature(intrinsics)]\n\nextern \"rust-intrinsic\" {\n    fn atomic_fence(); // ok!\n}\n```\n"),
 ("E0093",
  "\nYou declared an unknown intrinsic function. Erroneous code example:\n\n```compile_fail\n#![feature(intrinsics)]\n\nextern \"rust-intrinsic\" {\n    fn foo(); // error: unrecognized intrinsic function: `foo`\n}\n\nfn main() {\n    unsafe {\n        foo();\n    }\n}\n```\n\nPlease check you didn\'t make a mistake in the function\'s name. All intrinsic\nfunctions are defined in librustc_trans/trans/intrinsic.rs and in\nlibcore/intrinsics.rs in the Rust source code. Example:\n\n```\n#![feature(intrinsics)]\n\nextern \"rust-intrinsic\" {\n    fn atomic_fence(); // ok!\n}\n\nfn main() {\n    unsafe {\n        atomic_fence();\n    }\n}\n```\n"),
 ("E0094",
  "\nYou gave an invalid number of type parameters to an intrinsic function.\nErroneous code example:\n\n```compile_fail\n#![feature(intrinsics)]\n\nextern \"rust-intrinsic\" {\n    fn size_of<T, U>() -> usize; // error: intrinsic has wrong number\n                                 //        of type parameters\n}\n```\n\nPlease check that you provided the right number of lifetime parameters\nand verify with the function declaration in the Rust source code.\nExample:\n\n```\n#![feature(intrinsics)]\n\nextern \"rust-intrinsic\" {\n    fn size_of<T>() -> usize; // ok!\n}\n```\n"),
 ("E0101",
  "\nYou hit this error because the compiler lacks the information to\ndetermine a type for this expression. Erroneous code example:\n\n```compile_fail\nfn main() {\n    let x = |_| {}; // error: cannot determine a type for this expression\n}\n```\n\nYou have two possibilities to solve this situation:\n * Give an explicit definition of the expression\n * Infer the expression\n\nExamples:\n\n```\nfn main() {\n    let x = |_ : u32| {}; // ok!\n    // or:\n    let x = |_| {};\n    x(0u32);\n}\n```\n"),
 ("E0102",
  "\nYou hit this error because the compiler lacks the information to\ndetermine the type of this variable. Erroneous code example:\n\n```compile_fail\nfn main() {\n    // could be an array of anything\n    let x = []; // error: cannot determine a type for this local variable\n}\n```\n\nTo solve this situation, constrain the type of the variable.\nExamples:\n\n```\n#![allow(unused_variables)]\n\nfn main() {\n    let x: [u8; 0] = [];\n}\n```\n"),
 ("E0106",
  "\nThis error indicates that a lifetime is missing from a type. If it is an error\ninside a function signature, the problem may be with failing to adhere to the\nlifetime elision rules (see below).\n\nHere are some simple examples of where you\'ll run into this error:\n\n```compile_fail\nstruct Foo { x: &bool }        // error\nstruct Foo<\'a> { x: &\'a bool } // correct\n\nenum Bar { A(u8), B(&bool), }        // error\nenum Bar<\'a> { A(u8), B(&\'a bool), } // correct\n\ntype MyStr = &str;        // error\ntype MyStr<\'a> = &\'a str; // correct\n```\n\nLifetime elision is a special, limited kind of inference for lifetimes in\nfunction signatures which allows you to leave out lifetimes in certain cases.\nFor more background on lifetime elision see [the book][book-le].\n\nThe lifetime elision rules require that any function signature with an elided\noutput lifetime must either have\n\n - exactly one input lifetime\n - or, multiple input lifetimes, but the function must also be a method with a\n   `&self` or `&mut self` receiver\n\nIn the first case, the output lifetime is inferred to be the same as the unique\ninput lifetime. In the second case, the lifetime is instead inferred to be the\nsame as the lifetime on `&self` or `&mut self`.\n\nHere are some examples of elision errors:\n\n```compile_fail\n// error, no input lifetimes\nfn foo() -> &str { }\n\n// error, `x` and `y` have distinct lifetimes inferred\nfn bar(x: &str, y: &str) -> &str { }\n\n// error, `y`\'s lifetime is inferred to be distinct from `x`\'s\nfn baz<\'a>(x: &\'a str, y: &str) -> &str { }\n```\n\n[book-le]: https://doc.rust-lang.org/nightly/book/lifetimes.html#lifetime-elision\n"),
 ("E0107",
  "\nThis error means that an incorrect number of lifetime parameters were provided\nfor a type (like a struct or enum) or trait.\n\nSome basic examples include:\n\n```compile_fail\nstruct Foo<\'a>(&\'a str);\nenum Bar { A, B, C }\n\nstruct Baz<\'a> {\n    foo: Foo,     // error: expected 1, found 0\n    bar: Bar<\'a>, // error: expected 0, found 1\n}\n```\n\nHere\'s an example that is currently an error, but may work in a future version\nof Rust:\n\n```compile_fail\nstruct Foo<\'a>(&\'a str);\n\ntrait Quux { }\nimpl Quux for Foo { } // error: expected 1, found 0\n```\n\nLifetime elision in implementation headers was part of the lifetime elision\nRFC. It is, however, [currently unimplemented][iss15872].\n\n[iss15872]: https://github.com/rust-lang/rust/issues/15872\n"),
 ("E0116",
  "\nYou can only define an inherent implementation for a type in the same crate\nwhere the type was defined. For example, an `impl` block as below is not allowed\nsince `Vec` is defined in the standard library:\n\n```compile_fail\nimpl Vec<u8> { } // error\n```\n\nTo fix this problem, you can do either of these things:\n\n - define a trait that has the desired associated functions/types/constants and\n   implement the trait for the type in question\n - define a new type wrapping the type and define an implementation on the new\n   type\n\nNote that using the `type` keyword does not work here because `type` only\nintroduces a type alias:\n\n```compile_fail\ntype Bytes = Vec<u8>;\n\nimpl Bytes { } // error, same as above\n```\n"),
 ("E0117",
  "\nThis error indicates a violation of one of Rust\'s orphan rules for trait\nimplementations. The rule prohibits any implementation of a foreign trait (a\ntrait defined in another crate) where\n\n - the type that is implementing the trait is foreign\n - all of the parameters being passed to the trait (if there are any) are also\n   foreign.\n\nHere\'s one example of this error:\n\n```compile_fail\nimpl Drop for u32 {}\n```\n\nTo avoid this kind of error, ensure that at least one local type is referenced\nby the `impl`:\n\n```ignore\npub struct Foo; // you define your type in your crate\n\nimpl Drop for Foo { // and you can implement the trait on it!\n    // code of trait implementation here\n}\n\nimpl From<Foo> for i32 { // or you use a type from your crate as\n                         // a type parameter\n    fn from(i: Foo) -> i32 {\n        0\n    }\n}\n```\n\nAlternatively, define a trait locally and implement that instead:\n\n```\ntrait Bar {\n    fn get(&self) -> usize;\n}\n\nimpl Bar for u32 {\n    fn get(&self) -> usize { 0 }\n}\n```\n\nFor information on the design of the orphan rules, see [RFC 1023].\n\n[RFC 1023]: https://github.com/rust-lang/rfcs/pull/1023\n"),
 ("E0118",
  "\nYou\'re trying to write an inherent implementation for something which isn\'t a\nstruct nor an enum. Erroneous code example:\n\n```compile_fail\nimpl (u8, u8) { // error: no base type found for inherent implementation\n    fn get_state(&self) -> String {\n        // ...\n    }\n}\n```\n\nTo fix this error, please implement a trait on the type or wrap it in a struct.\nExample:\n\n```\n// we create a trait here\ntrait LiveLongAndProsper {\n    fn get_state(&self) -> String;\n}\n\n// and now you can implement it on (u8, u8)\nimpl LiveLongAndProsper for (u8, u8) {\n    fn get_state(&self) -> String {\n        \"He\'s dead, Jim!\".to_owned()\n    }\n}\n```\n\nAlternatively, you can create a newtype. A newtype is a wrapping tuple-struct.\nFor example, `NewType` is a newtype over `Foo` in `struct NewType(Foo)`.\nExample:\n\n```\nstruct TypeWrapper((u8, u8));\n\nimpl TypeWrapper {\n    fn get_state(&self) -> String {\n        \"Fascinating!\".to_owned()\n    }\n}\n```\n"),
 ("E0119",
  "\nThere are conflicting trait implementations for the same type.\nExample of erroneous code:\n\n```compile_fail\ntrait MyTrait {\n    fn get(&self) -> usize;\n}\n\nimpl<T> MyTrait for T {\n    fn get(&self) -> usize { 0 }\n}\n\nstruct Foo {\n    value: usize\n}\n\nimpl MyTrait for Foo { // error: conflicting implementations of trait\n                       //        `MyTrait` for type `Foo`\n    fn get(&self) -> usize { self.value }\n}\n```\n\nWhen looking for the implementation for the trait, the compiler finds\nboth the `impl<T> MyTrait for T` where T is all types and the `impl\nMyTrait for Foo`. Since a trait cannot be implemented multiple times,\nthis is an error. So, when you write:\n\n```\ntrait MyTrait {\n    fn get(&self) -> usize;\n}\n\nimpl<T> MyTrait for T {\n    fn get(&self) -> usize { 0 }\n}\n```\n\nThis makes the trait implemented on all types in the scope. So if you\ntry to implement it on another one after that, the implementations will\nconflict. Example:\n\n```\ntrait MyTrait {\n    fn get(&self) -> usize;\n}\n\nimpl<T> MyTrait for T {\n    fn get(&self) -> usize { 0 }\n}\n\nstruct Foo;\n\nfn main() {\n    let f = Foo;\n\n    f.get(); // the trait is implemented so we can use it\n}\n```\n"),
 ("E0120",
  "\nAn attempt was made to implement Drop on a trait, which is not allowed: only\nstructs and enums can implement Drop. An example causing this error:\n\n```compile_fail\ntrait MyTrait {}\n\nimpl Drop for MyTrait {\n    fn drop(&mut self) {}\n}\n```\n\nA workaround for this problem is to wrap the trait up in a struct, and implement\nDrop on that. An example is shown below:\n\n```\ntrait MyTrait {}\nstruct MyWrapper<T: MyTrait> { foo: T }\n\nimpl <T: MyTrait> Drop for MyWrapper<T> {\n    fn drop(&mut self) {}\n}\n\n```\n\nAlternatively, wrapping trait objects requires something like the following:\n\n```\ntrait MyTrait {}\n\n//or Box<MyTrait>, if you wanted an owned trait object\nstruct MyWrapper<\'a> { foo: &\'a MyTrait }\n\nimpl <\'a> Drop for MyWrapper<\'a> {\n    fn drop(&mut self) {}\n}\n```\n"),
 ("E0121",
  "\nIn order to be consistent with Rust\'s lack of global type inference, type\nplaceholders are disallowed by design in item signatures.\n\nExamples of this error include:\n\n```compile_fail\nfn foo() -> _ { 5 } // error, explicitly write out the return type instead\n\nstatic BAR: _ = \"test\"; // error, explicitly write out the type instead\n```\n"),
 ("E0122",
  "\nAn attempt was made to add a generic constraint to a type alias. While Rust will\nallow this with a warning, it will not currently enforce the constraint.\nConsider the example below:\n\n```\ntrait Foo{}\n\ntype MyType<R: Foo> = (R, ());\n\nfn main() {\n    let t: MyType<u32>;\n}\n```\n\nWe\'re able to declare a variable of type `MyType<u32>`, despite the fact that\n`u32` does not implement `Foo`. As a result, one should avoid using generic\nconstraints in concert with type aliases.\n"),
 ("E0124",
  "\nYou declared two fields of a struct with the same name. Erroneous code\nexample:\n\n```compile_fail\nstruct Foo {\n    field1: i32,\n    field1: i32, // error: field is already declared\n}\n```\n\nPlease verify that the field names have been correctly spelled. Example:\n\n```\nstruct Foo {\n    field1: i32,\n    field2: i32, // ok!\n}\n```\n"),
 ("E0128",
  "\nType parameter defaults can only use parameters that occur before them.\nErroneous code example:\n\n```compile_fail\nstruct Foo<T=U, U=()> {\n    field1: T,\n    filed2: U,\n}\n// error: type parameters with a default cannot use forward declared\n// identifiers\n```\n\nSince type parameters are evaluated in-order, you may be able to fix this issue\nby doing:\n\n```\nstruct Foo<U=(), T=U> {\n    field1: T,\n    filed2: U,\n}\n```\n\nPlease also verify that this wasn\'t because of a name-clash and rename the type\nparameter if so.\n"),
 ("E0130",
  "\nYou declared a pattern as an argument in a foreign function declaration.\nErroneous code example:\n\n```compile_fail\nextern {\n    fn foo((a, b): (u32, u32)); // error: patterns aren\'t allowed in foreign\n                                //        function declarations\n}\n```\n\nPlease replace the pattern argument with a regular one. Example:\n\n```\nstruct SomeStruct {\n    a: u32,\n    b: u32,\n}\n\nextern {\n    fn foo(s: SomeStruct); // ok!\n}\n```\n\nOr:\n\n```\nextern {\n    fn foo(a: (u32, u32)); // ok!\n}\n```\n"),
 ("E0163",
  "\nThis error means that an attempt was made to match an enum variant as a\nstruct type when the variant isn\'t a struct type:\n\n```compile_fail\nenum Foo { B(u32) }\n\nfn bar(foo: Foo) -> u32 {\n    match foo {\n        B{i} => i, // error E0163\n    }\n}\n```\n\nTry using `()` instead:\n\n```\nenum Foo { B(u32) }\n\nfn bar(foo: Foo) -> u32 {\n    match foo {\n        Foo::B(i) => i,\n    }\n}\n```\n"),
 ("E0164",
  "\nThis error means that an attempt was made to match a struct type enum\nvariant as a non-struct type:\n\n```compile_fail\nenum Foo { B { i: u32 } }\n\nfn bar(foo: Foo) -> u32 {\n    match foo {\n        Foo::B(i) => i, // error E0164\n    }\n}\n```\n\nTry using `{}` instead:\n\n```\nenum Foo { B { i: u32 } }\n\nfn bar(foo: Foo) -> u32 {\n    match foo {\n        Foo::B{i} => i,\n    }\n}\n```\n"),
 ("E0166",
  "\nThis error means that the compiler found a return expression in a function\nmarked as diverging. A function diverges if it has `!` in the place of the\nreturn type in its signature. For example:\n\n```compile_fail\nfn foo() -> ! { return; } // error\n```\n\nFor a function that diverges, every control path in the function must never\nreturn, for example with a `loop` that never breaks or a call to another\ndiverging function (such as `panic!()`).\n"),
 ("E0172",
  "\nThis error means that an attempt was made to specify the type of a variable with\na combination of a concrete type and a trait. Consider the following example:\n\n```compile_fail\nfn foo(bar: i32+std::fmt::Display) {}\n```\n\nThe code is trying to specify that we want to receive a signed 32-bit integer\nwhich also implements `Display`. This doesn\'t make sense: when we pass `i32`, a\nconcrete type, it implicitly includes all of the traits that it implements.\nThis includes `Display`, `Debug`, `Clone`, and a host of others.\n\nIf `i32` implements the trait we desire, there\'s no need to specify the trait\nseparately. If it does not, then we need to `impl` the trait for `i32` before\npassing it into `foo`. Either way, a fixed definition for `foo` will look like\nthe following:\n\n```\nfn foo(bar: i32) {}\n```\n\nTo learn more about traits, take a look at the Book:\n\nhttps://doc.rust-lang.org/book/traits.html\n"),
 ("E0178",
  "\nIn types, the `+` type operator has low precedence, so it is often necessary\nto use parentheses.\n\nFor example:\n\n```compile_fail\ntrait Foo {}\n\nstruct Bar<\'a> {\n    w: &\'a Foo + Copy,   // error, use &\'a (Foo + Copy)\n    x: &\'a Foo + \'a,     // error, use &\'a (Foo + \'a)\n    y: &\'a mut Foo + \'a, // error, use &\'a mut (Foo + \'a)\n    z: fn() -> Foo + \'a, // error, use fn() -> (Foo + \'a)\n}\n```\n\nMore details can be found in [RFC 438].\n\n[RFC 438]: https://github.com/rust-lang/rfcs/pull/438\n"),
 ("E0184",
  "\nExplicitly implementing both Drop and Copy for a type is currently disallowed.\nThis feature can make some sense in theory, but the current implementation is\nincorrect and can lead to memory unsafety (see [issue #20126][iss20126]), so\nit has been disabled for now.\n\n[iss20126]: https://github.com/rust-lang/rust/issues/20126\n"),
 ("E0185",
  "\nAn associated function for a trait was defined to be static, but an\nimplementation of the trait declared the same function to be a method (i.e. to\ntake a `self` parameter).\n\nHere\'s an example of this error:\n\n```compile_fail\ntrait Foo {\n    fn foo();\n}\n\nstruct Bar;\n\nimpl Foo for Bar {\n    // error, method `foo` has a `&self` declaration in the impl, but not in\n    // the trait\n    fn foo(&self) {}\n}\n"),
 ("E0186",
  "\nAn associated function for a trait was defined to be a method (i.e. to take a\n`self` parameter), but an implementation of the trait declared the same function\nto be static.\n\nHere\'s an example of this error:\n\n```compile_fail\ntrait Foo {\n    fn foo(&self);\n}\n\nstruct Bar;\n\nimpl Foo for Bar {\n    // error, method `foo` has a `&self` declaration in the trait, but not in\n    // the impl\n    fn foo() {}\n}\n```\n"),
 ("E0191",
  "\nTrait objects need to have all associated types specified. Erroneous code\nexample:\n\n```compile_fail\ntrait Trait {\n    type Bar;\n}\n\ntype Foo = Trait; // error: the value of the associated type `Bar` (from\n                  //        the trait `Trait`) must be specified\n```\n\nPlease verify you specified all associated types of the trait and that you\nused the right trait. Example:\n\n```\ntrait Trait {\n    type Bar;\n}\n\ntype Foo = Trait<Bar=i32>; // ok!\n```\n"),
 ("E0192",
  "\nNegative impls are only allowed for traits with default impls. For more\ninformation see the [opt-in builtin traits RFC](https://github.com/rust-lang/\nrfcs/blob/master/text/0019-opt-in-builtin-traits.md).\n"),
 ("E0193",
  "\n`where` clauses must use generic type parameters: it does not make sense to use\nthem otherwise. An example causing this error:\n\n```compile_fail\ntrait Foo {\n    fn bar(&self);\n}\n\n#[derive(Copy,Clone)]\nstruct Wrapper<T> {\n    Wrapped: T\n}\n\nimpl Foo for Wrapper<u32> where Wrapper<u32>: Clone {\n    fn bar(&self) { }\n}\n```\n\nThis use of a `where` clause is strange - a more common usage would look\nsomething like the following:\n\n```\ntrait Foo {\n    fn bar(&self);\n}\n\n#[derive(Copy,Clone)]\nstruct Wrapper<T> {\n    Wrapped: T\n}\nimpl <T> Foo for Wrapper<T> where Wrapper<T>: Clone {\n    fn bar(&self) { }\n}\n```\n\nHere, we\'re saying that the implementation exists on Wrapper only when the\nwrapped type `T` implements `Clone`. The `where` clause is important because\nsome types will not implement `Clone`, and thus will not get this method.\n\nIn our erroneous example, however, we\'re referencing a single concrete type.\nSince we know for certain that `Wrapper<u32>` implements `Clone`, there\'s no\nreason to also specify it in a `where` clause.\n"),
 ("E0194",
  "\nA type parameter was declared which shadows an existing one. An example of this\nerror:\n\n```compile_fail\ntrait Foo<T> {\n    fn do_something(&self) -> T;\n    fn do_something_else<T: Clone>(&self, bar: T);\n}\n```\n\nIn this example, the trait `Foo` and the trait method `do_something_else` both\ndefine a type parameter `T`. This is not allowed: if the method wishes to\ndefine a type parameter, it must use a different name for it.\n"),
 ("E0195",
  "\nYour method\'s lifetime parameters do not match the trait declaration.\nErroneous code example:\n\n```compile_fail\ntrait Trait {\n    fn bar<\'a,\'b:\'a>(x: &\'a str, y: &\'b str);\n}\n\nstruct Foo;\n\nimpl Trait for Foo {\n    fn bar<\'a,\'b>(x: &\'a str, y: &\'b str) {\n    // error: lifetime parameters or bounds on method `bar`\n    // do not match the trait declaration\n    }\n}\n```\n\nThe lifetime constraint `\'b` for bar() implementation does not match the\ntrait declaration. Ensure lifetime declarations match exactly in both trait\ndeclaration and implementation. Example:\n\n```\ntrait Trait {\n    fn t<\'a,\'b:\'a>(x: &\'a str, y: &\'b str);\n}\n\nstruct Foo;\n\nimpl Trait for Foo {\n    fn t<\'a,\'b:\'a>(x: &\'a str, y: &\'b str) { // ok!\n    }\n}\n```\n"),
 ("E0197",
  "\nInherent implementations (one that do not implement a trait but provide\nmethods associated with a type) are always safe because they are not\nimplementing an unsafe trait. Removing the `unsafe` keyword from the inherent\nimplementation will resolve this error.\n\n```compile_fail\nstruct Foo;\n\n// this will cause this error\nunsafe impl Foo { }\n// converting it to this will fix it\nimpl Foo { }\n```\n"),
 ("E0198",
  "\nA negative implementation is one that excludes a type from implementing a\nparticular trait. Not being able to use a trait is always a safe operation,\nso negative implementations are always safe and never need to be marked as\nunsafe.\n\n```compile_fail\n#![feature(optin_builtin_traits)]\n\nstruct Foo;\n\n// unsafe is unnecessary\nunsafe impl !Clone for Foo { }\n```\n\nThis will compile:\n\n```\n#![feature(optin_builtin_traits)]\n\nstruct Foo;\n\ntrait Enterprise {}\n\nimpl Enterprise for .. { }\n\nimpl !Enterprise for Foo { }\n```\n\nPlease note that negative impls are only allowed for traits with default impls.\n"),
 ("E0199",
  "\nSafe traits should not have unsafe implementations, therefore marking an\nimplementation for a safe trait unsafe will cause a compiler error. Removing\nthe unsafe marker on the trait noted in the error will resolve this problem.\n\n```compile_fail\nstruct Foo;\n\ntrait Bar { }\n\n// this won\'t compile because Bar is safe\nunsafe impl Bar for Foo { }\n// this will compile\nimpl Bar for Foo { }\n```\n"),
 ("E0200",
  "\nUnsafe traits must have unsafe implementations. This error occurs when an\nimplementation for an unsafe trait isn\'t marked as unsafe. This may be resolved\nby marking the unsafe implementation as unsafe.\n\n```compile_fail\nstruct Foo;\n\nunsafe trait Bar { }\n\n// this won\'t compile because Bar is unsafe and impl isn\'t unsafe\nimpl Bar for Foo { }\n// this will compile\nunsafe impl Bar for Foo { }\n```\n"),
 ("E0201",
  "\nIt is an error to define two associated items (like methods, associated types,\nassociated functions, etc.) with the same identifier.\n\nFor example:\n\n```compile_fail\nstruct Foo(u8);\n\nimpl Foo {\n    fn bar(&self) -> bool { self.0 > 5 }\n    fn bar() {} // error: duplicate associated function\n}\n\ntrait Baz {\n    type Quux;\n    fn baz(&self) -> bool;\n}\n\nimpl Baz for Foo {\n    type Quux = u32;\n\n    fn baz(&self) -> bool { true }\n\n    // error: duplicate method\n    fn baz(&self) -> bool { self.0 > 5 }\n\n    // error: duplicate associated type\n    type Quux = u32;\n}\n```\n\nNote, however, that items with the same name are allowed for inherent `impl`\nblocks that don\'t overlap:\n\n```\nstruct Foo<T>(T);\n\nimpl Foo<u8> {\n    fn bar(&self) -> bool { self.0 > 5 }\n}\n\nimpl Foo<bool> {\n    fn bar(&self) -> bool { self.0 }\n}\n```\n"),
 ("E0202",
  "\nInherent associated types were part of [RFC 195] but are not yet implemented.\nSee [the tracking issue][iss8995] for the status of this implementation.\n\n[RFC 195]: https://github.com/rust-lang/rfcs/pull/195\n[iss8995]: https://github.com/rust-lang/rust/issues/8995\n"),
 ("E0204",
  "\nAn attempt to implement the `Copy` trait for a struct failed because one of the\nfields does not implement `Copy`. To fix this, you must implement `Copy` for the\nmentioned field. Note that this may not be possible, as in the example of\n\n```compile_fail\nstruct Foo {\n    foo : Vec<u32>,\n}\n\nimpl Copy for Foo { }\n```\n\nThis fails because `Vec<T>` does not implement `Copy` for any `T`.\n\nHere\'s another example that will fail:\n\n```compile_fail\n#[derive(Copy)]\nstruct Foo<\'a> {\n    ty: &\'a mut bool,\n}\n```\n\nThis fails because `&mut T` is not `Copy`, even when `T` is `Copy` (this\ndiffers from the behavior for `&T`, which is always `Copy`).\n"),
 ("E0205",
  "\nAn attempt to implement the `Copy` trait for an enum failed because one of the\nvariants does not implement `Copy`. To fix this, you must implement `Copy` for\nthe mentioned variant. Note that this may not be possible, as in the example of\n\n```compile_fail\nenum Foo {\n    Bar(Vec<u32>),\n    Baz,\n}\n\nimpl Copy for Foo { }\n```\n\nThis fails because `Vec<T>` does not implement `Copy` for any `T`.\n\nHere\'s another example that will fail:\n\n```compile_fail\n#[derive(Copy)]\nenum Foo<\'a> {\n    Bar(&\'a mut bool),\n    Baz\n}\n```\n\nThis fails because `&mut T` is not `Copy`, even when `T` is `Copy` (this\ndiffers from the behavior for `&T`, which is always `Copy`).\n"),
 ("E0206",
  "\nYou can only implement `Copy` for a struct or enum. Both of the following\nexamples will fail, because neither `i32` (primitive type) nor `&\'static Bar`\n(reference to `Bar`) is a struct or enum:\n\n```compile_fail\ntype Foo = i32;\nimpl Copy for Foo { } // error\n\n#[derive(Copy, Clone)]\nstruct Bar;\nimpl Copy for &\'static Bar { } // error\n```\n"),
 ("E0207",
  "\nYou declared an unused type parameter when implementing a trait on an object.\nErroneous code example:\n\n```compile_fail\ntrait MyTrait {\n    fn get(&self) -> usize;\n}\n\nstruct Foo;\n\nimpl<T> MyTrait for Foo {\n    fn get(&self) -> usize {\n        0\n    }\n}\n```\n\nPlease check your object definition and remove unused type\nparameter(s). Example:\n\n```\ntrait MyTrait {\n    fn get(&self) -> usize;\n}\n\nstruct Foo;\n\nimpl MyTrait for Foo {\n    fn get(&self) -> usize {\n        0\n    }\n}\n```\n"),
 ("E0210",
  "\nThis error indicates a violation of one of Rust\'s orphan rules for trait\nimplementations. The rule concerns the use of type parameters in an\nimplementation of a foreign trait (a trait defined in another crate), and\nstates that type parameters must be \"covered\" by a local type. To understand\nwhat this means, it is perhaps easiest to consider a few examples.\n\nIf `ForeignTrait` is a trait defined in some external crate `foo`, then the\nfollowing trait `impl` is an error:\n\n```compile_fail\nextern crate foo;\nuse foo::ForeignTrait;\n\nimpl<T> ForeignTrait for T { } // error\n```\n\nTo work around this, it can be covered with a local type, `MyType`:\n\n```ignore\nstruct MyType<T>(T);\nimpl<T> ForeignTrait for MyType<T> { } // Ok\n```\n\nPlease note that a type alias is not sufficient.\n\nFor another example of an error, suppose there\'s another trait defined in `foo`\nnamed `ForeignTrait2` that takes two type parameters. Then this `impl` results\nin the same rule violation:\n\n```compile_fail\nstruct MyType2;\nimpl<T> ForeignTrait2<T, MyType<T>> for MyType2 { } // error\n```\n\nThe reason for this is that there are two appearances of type parameter `T` in\nthe `impl` header, both as parameters for `ForeignTrait2`. The first appearance\nis uncovered, and so runs afoul of the orphan rule.\n\nConsider one more example:\n\n```ignore\nimpl<T> ForeignTrait2<MyType<T>, T> for MyType2 { } // Ok\n```\n\nThis only differs from the previous `impl` in that the parameters `T` and\n`MyType<T>` for `ForeignTrait2` have been swapped. This example does *not*\nviolate the orphan rule; it is permitted.\n\nTo see why that last example was allowed, you need to understand the general\nrule. Unfortunately this rule is a bit tricky to state. Consider an `impl`:\n\n```ignore\nimpl<P1, ..., Pm> ForeignTrait<T1, ..., Tn> for T0 { ... }\n```\n\nwhere `P1, ..., Pm` are the type parameters of the `impl` and `T0, ..., Tn`\nare types. One of the types `T0, ..., Tn` must be a local type (this is another\norphan rule, see the explanation for E0117). Let `i` be the smallest integer\nsuch that `Ti` is a local type. Then no type parameter can appear in any of the\n`Tj` for `j < i`.\n\nFor information on the design of the orphan rules, see [RFC 1023].\n\n[RFC 1023]: https://github.com/rust-lang/rfcs/pull/1023\n"),
 ("E0214",
  "\nA generic type was described using parentheses rather than angle brackets. For\nexample:\n\n```compile_fail\nfn main() {\n    let v: Vec(&str) = vec![\"foo\"];\n}\n```\n\nThis is not currently supported: `v` should be defined as `Vec<&str>`.\nParentheses are currently only used with generic types when defining parameters\nfor `Fn`-family traits.\n"),
 ("E0220",
  "\nYou used an associated type which isn\'t defined in the trait.\nErroneous code example:\n\n```compile_fail\ntrait Trait {\n    type Bar;\n}\n\ntype Foo = Trait<F=i32>; // error: associated type `F` not found for\n                         //        `Trait`\n```\n\nPlease verify you used the right trait or you didn\'t misspell the\nassociated type name. Example:\n\n```\ntrait Trait {\n    type Bar;\n}\n\ntype Foo = Trait<Bar=i32>; // ok!\n```\n"),
 ("E0221",
  "\nAn attempt was made to retrieve an associated type, but the type was ambiguous.\nFor example:\n\n```compile_fail\ntrait T1 {}\ntrait T2 {}\n\ntrait Foo {\n    type A: T1;\n}\n\ntrait Bar : Foo {\n    type A: T2;\n    fn do_something() {\n        let _: Self::A;\n    }\n}\n```\n\nIn this example, `Foo` defines an associated type `A`. `Bar` inherits that type\nfrom `Foo`, and defines another associated type of the same name. As a result,\nwhen we attempt to use `Self::A`, it\'s ambiguous whether we mean the `A` defined\nby `Foo` or the one defined by `Bar`.\n\nThere are two options to work around this issue. The first is simply to rename\none of the types. Alternatively, one can specify the intended type using the\nfollowing syntax:\n\n```\ntrait T1 {}\ntrait T2 {}\n\ntrait Foo {\n    type A: T1;\n}\n\ntrait Bar : Foo {\n    type A: T2;\n    fn do_something() {\n        let _: <Self as Bar>::A;\n    }\n}\n```\n"),
 ("E0223",
  "\nAn attempt was made to retrieve an associated type, but the type was ambiguous.\nFor example:\n\n```compile_fail\ntrait MyTrait {type X; }\n\nfn main() {\n    let foo: MyTrait::X;\n}\n```\n\nThe problem here is that we\'re attempting to take the type of X from MyTrait.\nUnfortunately, the type of X is not defined, because it\'s only made concrete in\nimplementations of the trait. A working version of this code might look like:\n\n```\ntrait MyTrait {type X; }\nstruct MyStruct;\n\nimpl MyTrait for MyStruct {\n    type X = u32;\n}\n\nfn main() {\n    let foo: <MyStruct as MyTrait>::X;\n}\n```\n\nThis syntax specifies that we want the X type from MyTrait, as made concrete in\nMyStruct. The reason that we cannot simply use `MyStruct::X` is that MyStruct\nmight implement two different traits with identically-named associated types.\nThis syntax allows disambiguation between the two.\n"),
 ("E0225",
  "\nYou attempted to use multiple types as bounds for a closure or trait object.\nRust does not currently support this. A simple example that causes this error:\n\n```compile_fail\nfn main() {\n    let _: Box<std::io::Read + std::io::Write>;\n}\n```\n\nBuiltin traits are an exception to this rule: it\'s possible to have bounds of\none non-builtin type, plus any number of builtin types. For example, the\nfollowing compiles correctly:\n\n```\nfn main() {\n    let _: Box<std::io::Read + Send + Sync>;\n}\n```\n"),
 ("E0232",
  "\nThe attribute must have a value. Erroneous code example:\n\n```compile_fail\n#![feature(on_unimplemented)]\n\n#[rustc_on_unimplemented] // error: this attribute must have a value\ntrait Bar {}\n```\n\nPlease supply the missing value of the attribute. Example:\n\n```\n#![feature(on_unimplemented)]\n\n#[rustc_on_unimplemented = \"foo\"] // ok!\ntrait Bar {}\n```\n"),
 ("E0243",
  "\nThis error indicates that not enough type parameters were found in a type or\ntrait.\n\nFor example, the `Foo` struct below is defined to be generic in `T`, but the\ntype parameter is missing in the definition of `Bar`:\n\n```compile_fail\nstruct Foo<T> { x: T }\n\nstruct Bar { x: Foo }\n```\n"),
 ("E0244",
  "\nThis error indicates that too many type parameters were found in a type or\ntrait.\n\nFor example, the `Foo` struct below has no type parameters, but is supplied\nwith two in the definition of `Bar`:\n\n```compile_fail\nstruct Foo { x: bool }\n\nstruct Bar<S, T> { x: Foo<S, T> }\n```\n"),
 ("E0248",
  "\nThis error indicates an attempt to use a value where a type is expected. For\nexample:\n\n```compile_fail\nenum Foo {\n    Bar(u32)\n}\n\nfn do_something(x: Foo::Bar) { }\n```\n\nIn this example, we\'re attempting to take a type of `Foo::Bar` in the\ndo_something function. This is not legal: `Foo::Bar` is a value of type `Foo`,\nnot a distinct static type. Likewise, it\'s not legal to attempt to\n`impl Foo::Bar`: instead, you must `impl Foo` and then pattern match to specify\nbehavior for specific enum variants.\n"),
 ("E0249",
  "\nThis error indicates a constant expression for the array length was found, but\nit was not an integer (signed or unsigned) expression.\n\nSome examples of code that produces this error are:\n\n```compile_fail\nconst A: [u32; \"hello\"] = []; // error\nconst B: [u32; true] = []; // error\nconst C: [u32; 0.0] = []; // error\n"),
 ("E0250",
  "\nThere was an error while evaluating the expression for the length of a fixed-\nsize array type.\n\nSome examples of this error are:\n\n```compile_fail\n// divide by zero in the length expression\nconst A: [u32; 1/0] = [];\n\n// Rust currently will not evaluate the function `foo` at compile time\nfn foo() -> usize { 12 }\nconst B: [u32; foo()] = [];\n\n// it is an error to try to add `u8` and `f64`\nuse std::{f64, u8};\nconst C: [u32; u8::MAX + f64::EPSILON] = [];\n```\n"),
 ("E0318",
  "\nDefault impls for a trait must be located in the same crate where the trait was\ndefined. For more information see the [opt-in builtin traits RFC](https://github\n.com/rust-lang/rfcs/blob/master/text/0019-opt-in-builtin-traits.md).\n"),
 ("E0321",
  "\nA cross-crate opt-out trait was implemented on something which wasn\'t a struct\nor enum type. Erroneous code example:\n\n```compile_fail\n#![feature(optin_builtin_traits)]\n\nstruct Foo;\n\nimpl !Sync for Foo {}\n\nunsafe impl Send for &\'static Foo {\n// error: cross-crate traits with a default impl, like `core::marker::Send`,\n//        can only be implemented for a struct/enum type, not\n//        `&\'static Foo`\n```\n\nOnly structs and enums are permitted to impl Send, Sync, and other opt-out\ntrait, and the struct or enum must be local to the current crate. So, for\nexample, `unsafe impl Send for Rc<Foo>` is not allowed.\n"),
 ("E0322",
  "\nThe `Sized` trait is a special trait built-in to the compiler for types with a\nconstant size known at compile-time. This trait is automatically implemented\nfor types as needed by the compiler, and it is currently disallowed to\nexplicitly implement it for a type.\n"),
 ("E0323",
  "\nAn associated const was implemented when another trait item was expected.\nErroneous code example:\n\n```compile_fail\n#![feature(associated_consts)]\n\ntrait Foo {\n    type N;\n}\n\nstruct Bar;\n\nimpl Foo for Bar {\n    const N : u32 = 0;\n    // error: item `N` is an associated const, which doesn\'t match its\n    //        trait `<Bar as Foo>`\n}\n```\n\nPlease verify that the associated const wasn\'t misspelled and the correct trait\nwas implemented. Example:\n\n```\nstruct Bar;\n\ntrait Foo {\n    type N;\n}\n\nimpl Foo for Bar {\n    type N = u32; // ok!\n}\n```\n\nOr:\n\n```\n#![feature(associated_consts)]\n\nstruct Bar;\n\ntrait Foo {\n    const N : u32;\n}\n\nimpl Foo for Bar {\n    const N : u32 = 0; // ok!\n}\n```\n"),
 ("E0324",
  "\nA method was implemented when another trait item was expected. Erroneous\ncode example:\n\n```compile_fail\nstruct Bar;\n\ntrait Foo {\n    const N : u32;\n\n    fn M();\n}\n\nimpl Foo for Bar {\n    fn N() {}\n    // error: item `N` is an associated method, which doesn\'t match its\n    //        trait `<Bar as Foo>`\n}\n```\n\nTo fix this error, please verify that the method name wasn\'t misspelled and\nverify that you are indeed implementing the correct trait items. Example:\n\n```\n#![feature(associated_consts)]\n\nstruct Bar;\n\ntrait Foo {\n    const N : u32;\n\n    fn M();\n}\n\nimpl Foo for Bar {\n    const N : u32 = 0;\n\n    fn M() {} // ok!\n}\n```\n"),
 ("E0325",
  "\nAn associated type was implemented when another trait item was expected.\nErroneous code example:\n\n```compile_fail\nstruct Bar;\n\ntrait Foo {\n    const N : u32;\n}\n\nimpl Foo for Bar {\n    type N = u32;\n    // error: item `N` is an associated type, which doesn\'t match its\n    //        trait `<Bar as Foo>`\n}\n```\n\nPlease verify that the associated type name wasn\'t misspelled and your\nimplementation corresponds to the trait definition. Example:\n\n```\nstruct Bar;\n\ntrait Foo {\n    type N;\n}\n\nimpl Foo for Bar {\n    type N = u32; // ok!\n}\n```\n\nOr:\n\n```\n#![feature(associated_consts)]\n\nstruct Bar;\n\ntrait Foo {\n    const N : u32;\n}\n\nimpl Foo for Bar {\n    const N : u32 = 0; // ok!\n}\n```\n"),
 ("E0326",
  "\nThe types of any associated constants in a trait implementation must match the\ntypes in the trait definition. This error indicates that there was a mismatch.\n\nHere\'s an example of this error:\n\n```compile_fail\ntrait Foo {\n    const BAR: bool;\n}\n\nstruct Bar;\n\nimpl Foo for Bar {\n    const BAR: u32 = 5; // error, expected bool, found u32\n}\n```\n"),
 ("E0327",
  "\nYou cannot use associated items other than constant items as patterns. This\nincludes method items. Example of erroneous code:\n\n```compile_fail\nenum B {}\n\nimpl B {\n    fn bb() -> i32 { 0 }\n}\n\nfn main() {\n    match 0 {\n        B::bb => {} // error: associated items in match patterns must\n                    // be constants\n    }\n}\n```\n\nPlease check that you\'re not using a method as a pattern. Example:\n\n```\nenum B {\n    ba,\n    bb\n}\n\nfn main() {\n    match B::ba {\n        B::bb => {} // ok!\n        _ => {}\n    }\n}\n```\n"),
 ("E0329",
  "\nAn attempt was made to access an associated constant through either a generic\ntype parameter or `Self`. This is not supported yet. An example causing this\nerror is shown below:\n\n```compile_fail\n#![feature(associated_consts)]\n\ntrait Foo {\n    const BAR: f64;\n}\n\nstruct MyStruct;\n\nimpl Foo for MyStruct {\n    const BAR: f64 = 0f64;\n}\n\nfn get_bar_bad<F: Foo>(t: F) -> f64 {\n    F::BAR\n}\n```\n\nCurrently, the value of `BAR` for a particular type can only be accessed\nthrough a concrete type, as shown below:\n\n```ignore\n#![feature(associated_consts)]\n\ntrait Foo {\n    const BAR: f64;\n}\n\nstruct MyStruct;\n\nfn get_bar_good() -> f64 {\n    <MyStruct as Foo>::BAR\n}\n```\n"),
 ("E0366",
  "\nAn attempt was made to implement `Drop` on a concrete specialization of a\ngeneric type. An example is shown below:\n\n```compile_fail\nstruct Foo<T> {\n    t: T\n}\n\nimpl Drop for Foo<u32> {\n    fn drop(&mut self) {}\n}\n```\n\nThis code is not legal: it is not possible to specialize `Drop` to a subset of\nimplementations of a generic type. One workaround for this is to wrap the\ngeneric type, as shown below:\n\n```\nstruct Foo<T> {\n    t: T\n}\n\nstruct Bar {\n    t: Foo<u32>\n}\n\nimpl Drop for Bar {\n    fn drop(&mut self) {}\n}\n```\n"),
 ("E0367",
  "\nAn attempt was made to implement `Drop` on a specialization of a generic type.\nAn example is shown below:\n\n```compile_fail\ntrait Foo{}\n\nstruct MyStruct<T> {\n    t: T\n}\n\nimpl<T: Foo> Drop for MyStruct<T> {\n    fn drop(&mut self) {}\n}\n```\n\nThis code is not legal: it is not possible to specialize `Drop` to a subset of\nimplementations of a generic type. In order for this code to work, `MyStruct`\nmust also require that `T` implements `Foo`. Alternatively, another option is\nto wrap the generic type in another that specializes appropriately:\n\n```\ntrait Foo{}\n\nstruct MyStruct<T> {\n    t: T\n}\n\nstruct MyStructWrapper<T: Foo> {\n    t: MyStruct<T>\n}\n\nimpl <T: Foo> Drop for MyStructWrapper<T> {\n    fn drop(&mut self) {}\n}\n```\n"),
 ("E0368",
  "\nThis error indicates that a binary assignment operator like `+=` or `^=` was\napplied to a type that doesn\'t support it. For example:\n\n```compile_fail\nlet mut x = 12f32; // error: binary operation `<<` cannot be applied to\n                   //        type `f32`\n\nx <<= 2;\n```\n\nTo fix this error, please check that this type implements this binary\noperation. Example:\n\n```\nlet mut x = 12u32; // the `u32` type does implement the `ShlAssign` trait\n\nx <<= 2; // ok!\n```\n\nIt is also possible to overload most operators for your own type by\nimplementing the `[OP]Assign` traits from `std::ops`.\n\nAnother problem you might be facing is this: suppose you\'ve overloaded the `+`\noperator for some type `Foo` by implementing the `std::ops::Add` trait for\n`Foo`, but you find that using `+=` does not work, as in this example:\n\n```compile_fail\nuse std::ops::Add;\n\nstruct Foo(u32);\n\nimpl Add for Foo {\n    type Output = Foo;\n\n    fn add(self, rhs: Foo) -> Foo {\n        Foo(self.0 + rhs.0)\n    }\n}\n\nfn main() {\n    let mut x: Foo = Foo(5);\n    x += Foo(7); // error, `+= cannot be applied to the type `Foo`\n}\n```\n\nThis is because `AddAssign` is not automatically implemented, so you need to\nmanually implement it for your type.\n"),
 ("E0369",
  "\nA binary operation was attempted on a type which doesn\'t support it.\nErroneous code example:\n\n```compile_fail\nlet x = 12f32; // error: binary operation `<<` cannot be applied to\n               //        type `f32`\n\nx << 2;\n```\n\nTo fix this error, please check that this type implements this binary\noperation. Example:\n\n```\nlet x = 12u32; // the `u32` type does implement it:\n               // https://doc.rust-lang.org/stable/std/ops/trait.Shl.html\n\nx << 2; // ok!\n```\n\nIt is also possible to overload most operators for your own type by\nimplementing traits from `std::ops`.\n"),
 ("E0370",
  "\nThe maximum value of an enum was reached, so it cannot be automatically\nset in the next enum value. Erroneous code example:\n\n```compile_fail\nenum Foo {\n    X = 0x7fffffffffffffff,\n    Y, // error: enum discriminant overflowed on value after\n       //        9223372036854775807: i64; set explicitly via\n       //        Y = -9223372036854775808 if that is desired outcome\n}\n```\n\nTo fix this, please set manually the next enum value or put the enum variant\nwith the maximum value at the end of the enum. Examples:\n\n```\nenum Foo {\n    X = 0x7fffffffffffffff,\n    Y = 0, // ok!\n}\n```\n\nOr:\n\n```\nenum Foo {\n    Y = 0, // ok!\n    X = 0x7fffffffffffffff,\n}\n```\n"),
 ("E0371",
  "\nWhen `Trait2` is a subtrait of `Trait1` (for example, when `Trait2` has a\ndefinition like `trait Trait2: Trait1 { ... }`), it is not allowed to implement\n`Trait1` for `Trait2`. This is because `Trait2` already implements `Trait1` by\ndefinition, so it is not useful to do this.\n\nExample:\n\n```compile_fail\ntrait Foo { fn foo(&self) { } }\ntrait Bar: Foo { }\ntrait Baz: Bar { }\n\nimpl Bar for Baz { } // error, `Baz` implements `Bar` by definition\nimpl Foo for Baz { } // error, `Baz` implements `Bar` which implements `Foo`\nimpl Baz for Baz { } // error, `Baz` (trivially) implements `Baz`\nimpl Baz for Bar { } // Note: This is OK\n```\n"),
 ("E0374",
  "\nA struct without a field containing an unsized type cannot implement\n`CoerceUnsized`. An\n[unsized type](https://doc.rust-lang.org/book/unsized-types.html)\nis any type that the compiler doesn\'t know the length or alignment of at\ncompile time. Any struct containing an unsized type is also unsized.\n\nExample of erroneous code:\n\n```compile_fail\n#![feature(coerce_unsized)]\nuse std::ops::CoerceUnsized;\n\nstruct Foo<T: ?Sized> {\n    a: i32,\n}\n\n// error: Struct `Foo` has no unsized fields that need `CoerceUnsized`.\nimpl<T, U> CoerceUnsized<Foo<U>> for Foo<T>\n    where T: CoerceUnsized<U> {}\n```\n\n`CoerceUnsized` is used to coerce one struct containing an unsized type\ninto another struct containing a different unsized type. If the struct\ndoesn\'t have any fields of unsized types then you don\'t need explicit\ncoercion to get the types you want. To fix this you can either\nnot try to implement `CoerceUnsized` or you can add a field that is\nunsized to the struct.\n\nExample:\n\n```\n#![feature(coerce_unsized)]\nuse std::ops::CoerceUnsized;\n\n// We don\'t need to impl `CoerceUnsized` here.\nstruct Foo {\n    a: i32,\n}\n\n// We add the unsized type field to the struct.\nstruct Bar<T: ?Sized> {\n    a: i32,\n    b: T,\n}\n\n// The struct has an unsized field so we can implement\n// `CoerceUnsized` for it.\nimpl<T, U> CoerceUnsized<Bar<U>> for Bar<T>\n    where T: CoerceUnsized<U> {}\n```\n\nNote that `CoerceUnsized` is mainly used by smart pointers like `Box`, `Rc`\nand `Arc` to be able to mark that they can coerce unsized types that they\nare pointing at.\n"),
 ("E0375",
  "\nA struct with more than one field containing an unsized type cannot implement\n`CoerceUnsized`. This only occurs when you are trying to coerce one of the\ntypes in your struct to another type in the struct. In this case we try to\nimpl `CoerceUnsized` from `T` to `U` which are both types that the struct\ntakes. An [unsized type](https://doc.rust-lang.org/book/unsized-types.html)\nis any type that the compiler doesn\'t know the length or alignment of at\ncompile time. Any struct containing an unsized type is also unsized.\n\nExample of erroneous code:\n\n```compile_fail\n#![feature(coerce_unsized)]\nuse std::ops::CoerceUnsized;\n\nstruct Foo<T: ?Sized, U: ?Sized> {\n    a: i32,\n    b: T,\n    c: U,\n}\n\n// error: Struct `Foo` has more than one unsized field.\nimpl<T, U> CoerceUnsized<Foo<U, T>> for Foo<T, U> {}\n```\n\n`CoerceUnsized` only allows for coercion from a structure with a single\nunsized type field to another struct with a single unsized type field.\nIn fact Rust only allows for a struct to have one unsized type in a struct\nand that unsized type must be the last field in the struct. So having two\nunsized types in a single struct is not allowed by the compiler. To fix this\nuse only one field containing an unsized type in the struct and then use\nmultiple structs to manage each unsized type field you need.\n\nExample:\n\n```\n#![feature(coerce_unsized)]\nuse std::ops::CoerceUnsized;\n\nstruct Foo<T: ?Sized> {\n    a: i32,\n    b: T,\n}\n\nimpl <T, U> CoerceUnsized<Foo<U>> for Foo<T>\n    where T: CoerceUnsized<U> {}\n\nfn coerce_foo<T: CoerceUnsized<U>, U>(t: T) -> Foo<U> {\n    Foo { a: 12i32, b: t } // we use coercion to get the `Foo<U>` type we need\n}\n```\n\n"),
 ("E0376",
  "\nThe type you are trying to impl `CoerceUnsized` for is not a struct.\n`CoerceUnsized` can only be implemented for a struct. Unsized types are\nalready able to be coerced without an implementation of `CoerceUnsized`\nwhereas a struct containing an unsized type needs to know the unsized type\nfield it\'s containing is able to be coerced. An\n[unsized type](https://doc.rust-lang.org/book/unsized-types.html)\nis any type that the compiler doesn\'t know the length or alignment of at\ncompile time. Any struct containing an unsized type is also unsized.\n\nExample of erroneous code:\n\n```compile_fail\n#![feature(coerce_unsized)]\nuse std::ops::CoerceUnsized;\n\nstruct Foo<T: ?Sized> {\n    a: T,\n}\n\n// error: The type `U` is not a struct\nimpl<T, U> CoerceUnsized<U> for Foo<T> {}\n```\n\nThe `CoerceUnsized` trait takes a struct type. Make sure the type you are\nproviding to `CoerceUnsized` is a struct with only the last field containing an\nunsized type.\n\nExample:\n\n```\n#![feature(coerce_unsized)]\nuse std::ops::CoerceUnsized;\n\nstruct Foo<T> {\n    a: T,\n}\n\n// The `Foo<U>` is a struct so `CoerceUnsized` can be implemented\nimpl<T, U> CoerceUnsized<Foo<U>> for Foo<T> where T: CoerceUnsized<U> {}\n```\n\nNote that in Rust, structs can only contain an unsized type if the field\ncontaining the unsized type is the last and only unsized type field in the\nstruct.\n"),
 ("E0379",
  "\nTrait methods cannot be declared `const` by design. For more information, see\n[RFC 911].\n\n[RFC 911]: https://github.com/rust-lang/rfcs/pull/911\n"),
 ("E0380",
  "\nDefault impls are only allowed for traits with no methods or associated items.\nFor more information see the [opt-in builtin traits RFC](https://github.com/rust\n-lang/rfcs/blob/master/text/0019-opt-in-builtin-traits.md).\n"),
 ("E0390",
  "\nYou tried to implement methods for a primitive type. Erroneous code example:\n\n```compile_fail\nstruct Foo {\n    x: i32\n}\n\nimpl *mut Foo {}\n// error: only a single inherent implementation marked with\n//        `#[lang = \"mut_ptr\"]` is allowed for the `*mut T` primitive\n```\n\nThis isn\'t allowed, but using a trait to implement a method is a good solution.\nExample:\n\n```\nstruct Foo {\n    x: i32\n}\n\ntrait Bar {\n    fn bar();\n}\n\nimpl Bar for *mut Foo {\n    fn bar() {} // ok!\n}\n```\n"),
 ("E0391",
  "\nThis error indicates that some types or traits depend on each other\nand therefore cannot be constructed.\n\nThe following example contains a circular dependency between two traits:\n\n```compile_fail\ntrait FirstTrait : SecondTrait {\n\n}\n\ntrait SecondTrait : FirstTrait {\n\n}\n```\n"),
 ("E0392",
  "\nThis error indicates that a type or lifetime parameter has been declared\nbut not actually used. Here is an example that demonstrates the error:\n\n```compile_fail\nenum Foo<T> {\n    Bar\n}\n```\n\nIf the type parameter was included by mistake, this error can be fixed\nby simply removing the type parameter, as shown below:\n\n```\nenum Foo {\n    Bar\n}\n```\n\nAlternatively, if the type parameter was intentionally inserted, it must be\nused. A simple fix is shown below:\n\n```\nenum Foo<T> {\n    Bar(T)\n}\n```\n\nThis error may also commonly be found when working with unsafe code. For\nexample, when using raw pointers one may wish to specify the lifetime for\nwhich the pointed-at data is valid. An initial attempt (below) causes this\nerror:\n\n```compile_fail\nstruct Foo<\'a, T> {\n    x: *const T\n}\n```\n\nWe want to express the constraint that Foo should not outlive `\'a`, because\nthe data pointed to by `T` is only valid for that lifetime. The problem is\nthat there are no actual uses of `\'a`. It\'s possible to work around this\nby adding a PhantomData type to the struct, using it to tell the compiler\nto act as if the struct contained a borrowed reference `&\'a T`:\n\n```\nuse std::marker::PhantomData;\n\nstruct Foo<\'a, T: \'a> {\n    x: *const T,\n    phantom: PhantomData<&\'a T>\n}\n```\n\nPhantomData can also be used to express information about unused type\nparameters. You can read more about it in the API documentation:\n\nhttps://doc.rust-lang.org/std/marker/struct.PhantomData.html\n"),
 ("E0393",
  "\nA type parameter which references `Self` in its default value was not specified.\nExample of erroneous code:\n\n```compile_fail\ntrait A<T=Self> {}\n\nfn together_we_will_rule_the_galaxy(son: &A) {}\n// error: the type parameter `T` must be explicitly specified in an\n//        object type because its default value `Self` references the\n//        type `Self`\n```\n\nA trait object is defined over a single, fully-defined trait. With a regular\ndefault parameter, this parameter can just be substituted in. However, if the\ndefault parameter is `Self`, the trait changes for each concrete type; i.e.\n`i32` will be expected to implement `A<i32>`, `bool` will be expected to\nimplement `A<bool>`, etc... These types will not share an implementation of a\nfully-defined trait; instead they share implementations of a trait with\ndifferent parameters substituted in for each implementation. This is\nirreconcilable with what we need to make a trait object work, and is thus\ndisallowed. Making the trait concrete by explicitly specifying the value of the\ndefaulted parameter will fix this issue. Fixed example:\n\n```\ntrait A<T=Self> {}\n\nfn together_we_will_rule_the_galaxy(son: &A<i32>) {} // Ok!\n```\n"),
 ("E0439",
  "\nThe length of the platform-intrinsic function `simd_shuffle`\nwasn\'t specified. Erroneous code example:\n\n```compile_fail\n#![feature(platform_intrinsics)]\n\nextern \"platform-intrinsic\" {\n    fn simd_shuffle<A,B>(a: A, b: A, c: [u32; 8]) -> B;\n    // error: invalid `simd_shuffle`, needs length: `simd_shuffle`\n}\n```\n\nThe `simd_shuffle` function needs the length of the array passed as\nlast parameter in its name. Example:\n\n```\n#![feature(platform_intrinsics)]\n\nextern \"platform-intrinsic\" {\n    fn simd_shuffle8<A,B>(a: A, b: A, c: [u32; 8]) -> B;\n}\n```\n"),
 ("E0440",
  "\nA platform-specific intrinsic function has the wrong number of type\nparameters. Erroneous code example:\n\n```compile_fail\n#![feature(repr_simd)]\n#![feature(platform_intrinsics)]\n\n#[repr(simd)]\nstruct f64x2(f64, f64);\n\nextern \"platform-intrinsic\" {\n    fn x86_mm_movemask_pd<T>(x: f64x2) -> i32;\n    // error: platform-specific intrinsic has wrong number of type\n    //        parameters\n}\n```\n\nPlease refer to the function declaration to see if it corresponds\nwith yours. Example:\n\n```\n#![feature(repr_simd)]\n#![feature(platform_intrinsics)]\n\n#[repr(simd)]\nstruct f64x2(f64, f64);\n\nextern \"platform-intrinsic\" {\n    fn x86_mm_movemask_pd(x: f64x2) -> i32;\n}\n```\n"),
 ("E0441",
  "\nAn unknown platform-specific intrinsic function was used. Erroneous\ncode example:\n\n```compile_fail\n#![feature(repr_simd)]\n#![feature(platform_intrinsics)]\n\n#[repr(simd)]\nstruct i16x8(i16, i16, i16, i16, i16, i16, i16, i16);\n\nextern \"platform-intrinsic\" {\n    fn x86_mm_adds_ep16(x: i16x8, y: i16x8) -> i16x8;\n    // error: unrecognized platform-specific intrinsic function\n}\n```\n\nPlease verify that the function name wasn\'t misspelled, and ensure\nthat it is declared in the rust source code (in the file\nsrc/librustc_platform_intrinsics/x86.rs). Example:\n\n```\n#![feature(repr_simd)]\n#![feature(platform_intrinsics)]\n\n#[repr(simd)]\nstruct i16x8(i16, i16, i16, i16, i16, i16, i16, i16);\n\nextern \"platform-intrinsic\" {\n    fn x86_mm_adds_epi16(x: i16x8, y: i16x8) -> i16x8; // ok!\n}\n```\n"),
 ("E0442",
  "\nIntrinsic argument(s) and/or return value have the wrong type.\nErroneous code example:\n\n```compile_fail\n#![feature(repr_simd)]\n#![feature(platform_intrinsics)]\n\n#[repr(simd)]\nstruct i8x16(i8, i8, i8, i8, i8, i8, i8, i8,\n             i8, i8, i8, i8, i8, i8, i8, i8);\n#[repr(simd)]\nstruct i32x4(i32, i32, i32, i32);\n#[repr(simd)]\nstruct i64x2(i64, i64);\n\nextern \"platform-intrinsic\" {\n    fn x86_mm_adds_epi16(x: i8x16, y: i32x4) -> i64x2;\n    // error: intrinsic arguments/return value have wrong type\n}\n```\n\nTo fix this error, please refer to the function declaration to give\nit the awaited types. Example:\n\n```\n#![feature(repr_simd)]\n#![feature(platform_intrinsics)]\n\n#[repr(simd)]\nstruct i16x8(i16, i16, i16, i16, i16, i16, i16, i16);\n\nextern \"platform-intrinsic\" {\n    fn x86_mm_adds_epi16(x: i16x8, y: i16x8) -> i16x8; // ok!\n}\n```\n"),
 ("E0443",
  "\nIntrinsic argument(s) and/or return value have the wrong type.\nErroneous code example:\n\n```compile_fail\n#![feature(repr_simd)]\n#![feature(platform_intrinsics)]\n\n#[repr(simd)]\nstruct i16x8(i16, i16, i16, i16, i16, i16, i16, i16);\n#[repr(simd)]\nstruct i64x8(i64, i64, i64, i64, i64, i64, i64, i64);\n\nextern \"platform-intrinsic\" {\n    fn x86_mm_adds_epi16(x: i16x8, y: i16x8) -> i64x8;\n    // error: intrinsic argument/return value has wrong type\n}\n```\n\nTo fix this error, please refer to the function declaration to give\nit the awaited types. Example:\n\n```\n#![feature(repr_simd)]\n#![feature(platform_intrinsics)]\n\n#[repr(simd)]\nstruct i16x8(i16, i16, i16, i16, i16, i16, i16, i16);\n\nextern \"platform-intrinsic\" {\n    fn x86_mm_adds_epi16(x: i16x8, y: i16x8) -> i16x8; // ok!\n}\n```\n"),
 ("E0444",
  "\nA platform-specific intrinsic function has wrong number of arguments.\nErroneous code example:\n\n```compile_fail\n#![feature(repr_simd)]\n#![feature(platform_intrinsics)]\n\n#[repr(simd)]\nstruct f64x2(f64, f64);\n\nextern \"platform-intrinsic\" {\n    fn x86_mm_movemask_pd(x: f64x2, y: f64x2, z: f64x2) -> i32;\n    // error: platform-specific intrinsic has invalid number of arguments\n}\n```\n\nPlease refer to the function declaration to see if it corresponds\nwith yours. Example:\n\n```\n#![feature(repr_simd)]\n#![feature(platform_intrinsics)]\n\n#[repr(simd)]\nstruct f64x2(f64, f64);\n\nextern \"platform-intrinsic\" {\n    fn x86_mm_movemask_pd(x: f64x2) -> i32; // ok!\n}\n```\n"),
 ("E0516",
  "\nThe `typeof` keyword is currently reserved but unimplemented.\nErroneous code example:\n\n```compile_fail\nfn main() {\n    let x: typeof(92) = 92;\n}\n```\n\nTry using type inference instead. Example:\n\n```\nfn main() {\n    let x = 92;\n}\n```\n"),
 ("E0520",
  "\nA non-default implementation was already made on this type so it cannot be\nspecialized further. Erroneous code example:\n\n```compile_fail\n#![feature(specialization)]\n\ntrait SpaceLlama {\n    fn fly(&self);\n}\n\n// applies to all T\nimpl<T> SpaceLlama for T {\n    default fn fly(&self) {}\n}\n\n// non-default impl\n// applies to all `Clone` T and overrides the previous impl\nimpl<T: Clone> SpaceLlama for T {\n    fn fly(&self) {}\n}\n\n// since `i32` is clone, this conflicts with the previous implementation\nimpl SpaceLlama for i32 {\n    default fn fly(&self) {}\n    // error: item `fly` is provided by an `impl` that specializes\n    //        another, but the item in the parent `impl` is not marked\n    //        `default` and so it cannot be specialized.\n}\n```\n\nSpecialization only allows you to override `default` functions in\nimplementations.\n\nTo fix this error, you need to mark all the parent implementations as default.\nExample:\n\n```\n#![feature(specialization)]\n\ntrait SpaceLlama {\n    fn fly(&self);\n}\n\n// applies to all T\nimpl<T> SpaceLlama for T {\n    default fn fly(&self) {} // This is a parent implementation.\n}\n\n// applies to all `Clone` T; overrides the previous impl\nimpl<T: Clone> SpaceLlama for T {\n    default fn fly(&self) {} // This is a parent implementation but was\n                             // previously not a default one, causing the error\n}\n\n// applies to i32, overrides the previous two impls\nimpl SpaceLlama for i32 {\n    fn fly(&self) {} // And now that\'s ok!\n}\n```\n")]

Unstable (rustc_private)