1 // Copyright 2014 The Rust Project Developers. See the COPYRIGHT
2 // file at the top-level directory of this distribution and at
3 // http://rust-lang.org/COPYRIGHT.
5 // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or
6 // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license
7 // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your
8 // option. This file may not be copied, modified, or distributed
9 // except according to those terms.
11 #![allow(non_snake_case)]
13 register_long_diagnostics! {
16 A pattern used to match against an enum variant must provide a sub-pattern for
17 each field of the enum variant. This error indicates that a pattern attempted to
18 extract an incorrect number of fields from a variant.
22 Apple(String, String),
27 Here the `Apple` variant has two fields, and should be matched against like so:
31 Apple(String, String),
35 let x = Fruit::Apple(String::new(), String::new());
39 Fruit::Apple(a, b) => {},
44 Matching with the wrong number of fields has no sensible interpretation:
48 Apple(String, String),
52 let x = Fruit::Apple(String::new(), String::new());
56 Fruit::Apple(a) => {},
57 Fruit::Apple(a, b, c) => {},
61 Check how many fields the enum was declared with and ensure that your pattern
66 Each field of a struct can only be bound once in a pattern. Erroneous code
76 let x = Foo { a:1, b:2 };
78 let Foo { a: x, a: y } = x;
79 // error: field `a` bound multiple times in the pattern
83 Each occurrence of a field name binds the value of that field, so to fix this
84 error you will have to remove or alter the duplicate uses of the field name.
85 Perhaps you misspelled another field name? Example:
94 let x = Foo { a:1, b:2 };
96 let Foo { a: x, b: y } = x; // ok!
102 This error indicates that a struct pattern attempted to extract a non-existent
103 field from a struct. Struct fields are identified by the name used before the
104 colon `:` so struct patterns should resemble the declaration of the struct type
114 let thing = Thing { x: 1, y: 2 };
117 Thing { x: xfield, y: yfield } => {}
121 If you are using shorthand field patterns but want to refer to the struct field
122 by a different name, you should rename it explicitly.
132 let thing = Thing { x: 0, y: 0 };
147 let thing = Thing { x: 0, y: 0 };
150 Thing { x, y: z } => {}
156 This error indicates that a pattern for a struct fails to specify a sub-pattern
157 for every one of the struct's fields. Ensure that each field from the struct's
158 definition is mentioned in the pattern, or use `..` to ignore unwanted fields.
168 let d = Dog { name: "Rusty".to_string(), age: 8 };
170 // This is incorrect.
176 This is correct (explicit):
184 let d = Dog { name: "Rusty".to_string(), age: 8 };
187 Dog { name: ref n, age: x } => {}
190 // This is also correct (ignore unused fields).
192 Dog { age: x, .. } => {}
198 In a match expression, only numbers and characters can be matched against a
199 range. This is because the compiler checks that the range is non-empty at
200 compile-time, and is unable to evaluate arbitrary comparison functions. If you
201 want to capture values of an orderable type between two end-points, you can use
205 // The ordering relation for strings can't be evaluated at compile time,
206 // so this doesn't work:
208 "hello" ... "world" => {}
212 // This is a more general version, using a guard:
214 s if s >= "hello" && s <= "world" => {}
221 This error indicates that a pointer to a trait type cannot be implicitly
222 dereferenced by a pattern. Every trait defines a type, but because the
223 size of trait implementors isn't fixed, this type has no compile-time size.
224 Therefore, all accesses to trait types must be through pointers. If you
225 encounter this error you should try to avoid dereferencing the pointer.
228 let trait_obj: &SomeTrait = ...;
230 // This tries to implicitly dereference to create an unsized local variable.
231 let &invalid = trait_obj;
233 // You can call methods without binding to the value being pointed at.
234 trait_obj.method_one();
235 trait_obj.method_two();
238 You can read more about trait objects in the Trait Object section of the
241 https://doc.rust-lang.org/reference.html#trait-objects
245 The compiler doesn't know what method to call because more than one method
246 has the same prototype. Erroneous code example:
259 impl Trait1 for Test { fn foo() {} }
260 impl Trait2 for Test { fn foo() {} }
263 Test::foo() // error, which foo() to call?
267 To avoid this error, you have to keep only one of them and remove the others.
268 So let's take our example and fix it:
277 impl Trait1 for Test { fn foo() {} }
280 Test::foo() // and now that's good!
284 However, a better solution would be using fully explicit naming of type and
298 impl Trait1 for Test { fn foo() {} }
299 impl Trait2 for Test { fn foo() {} }
302 <Test as Trait1>::foo()
319 impl F for X { fn m(&self) { println!("I am F"); } }
320 impl G for X { fn m(&self) { println!("I am G"); } }
325 F::m(&f); // it displays "I am F"
326 G::m(&f); // it displays "I am G"
332 You tried to give a type parameter where it wasn't needed. Erroneous code
345 x.method::<i32>(); // Error: Test::method doesn't need type parameter!
349 To fix this error, just remove the type parameter:
361 x.method(); // OK, we're good!
367 This error occurrs when you pass too many or not enough type parameters to
368 a method. Erroneous code example:
374 fn method<T>(&self, v: &[T]) -> usize {
383 x.method::<i32, i32>(v); // error: only one type parameter is expected!
387 To fix it, just specify a correct number of type parameters:
393 fn method<T>(&self, v: &[T]) -> usize {
402 x.method::<i32>(v); // OK, we're good!
406 Please note on the last example that we could have called `method` like this:
414 It is not allowed to manually call destructors in Rust. It is also not
415 necessary to do this since `drop` is called automatically whenever a value goes
418 Here's an example of this error:
432 let mut x = Foo { x: -7 };
433 x.drop(); // error: explicit use of destructor method
439 You can't use type parameters on foreign items. Example of erroneous code:
442 extern { fn some_func<T>(x: T); }
445 To fix this, replace the type parameter with the specializations that you
449 extern { fn some_func_i32(x: i32); }
450 extern { fn some_func_i64(x: i64); }
455 Rust only supports variadic parameters for interoperability with C code in its
456 FFI. As such, variadic parameters can only be used with functions which are
457 using the C ABI. Examples of erroneous code:
460 extern "rust-call" { fn foo(x: u8, ...); }
464 fn foo(x: u8, ...) {}
467 To fix such code, put them in an extern "C" block:
470 extern "C" fn foo(x: u8, ...);
483 Items are missing in a trait implementation. Erroneous code example:
493 // error: not all trait items implemented, missing: `foo`
496 When trying to make some type implement a trait `Foo`, you must, at minimum,
497 provide implementations for all of `Foo`'s required methods (meaning the
498 methods that do not have default implementations), as well as any required
499 trait items like associated types or constants. Example:
515 This error indicates that an attempted implementation of a trait method
516 has the wrong number of type parameters.
518 For example, the trait below has a method `foo` with a type parameter `T`,
519 but the implementation of `foo` for the type `Bar` is missing this parameter:
523 fn foo<T: Default>(x: T) -> Self;
528 // error: method `foo` has 0 type parameters but its trait declaration has 1
531 fn foo(x: bool) -> Self { Bar }
537 This error indicates that an attempted implementation of a trait method
538 has the wrong number of function parameters.
540 For example, the trait below has a method `foo` with two function parameters
541 (`&self` and `u8`), but the implementation of `foo` for the type `Bar` omits
546 fn foo(&self, x: u8) -> bool;
551 // error: method `foo` has 1 parameter but the declaration in trait `Foo::foo`
554 fn foo(&self) -> bool { true }
560 The parameters of any trait method must match between a trait implementation
561 and the trait definition.
563 Here are a couple examples of this error:
574 // error, expected u16, found i16
577 // error, values differ in mutability
578 fn bar(&mut self) { }
584 It is not allowed to cast to a bool. If you are trying to cast a numeric type
585 to a bool, you can compare it with zero instead:
590 // Not allowed, won't compile
591 let x_is_nonzero = x as bool;
598 let x_is_nonzero = x != 0;
603 During a method call, a value is automatically dereferenced as many times as
604 needed to make the value's type match the method's receiver. The catch is that
605 the compiler will only attempt to dereference a number of times up to the
606 recursion limit (which can be set via the `recursion_limit` attribute).
608 For a somewhat artificial example:
610 ```compile_fail,ignore
611 #![recursion_limit="2"]
623 // error, reached the recursion limit while auto-dereferencing &&Foo
628 One fix may be to increase the recursion limit. Note that it is possible to
629 create an infinite recursion of dereferencing, in which case the only fix is to
630 somehow break the recursion.
634 When invoking closures or other implementations of the function traits `Fn`,
635 `FnMut` or `FnOnce` using call notation, the number of parameters passed to the
636 function must match its definition.
638 An example using a closure:
642 let a = f(); // invalid, too few parameters
643 let b = f(4); // this works!
644 let c = f(2, 3); // invalid, too many parameters
647 A generic function must be treated similarly:
650 fn foo<F: Fn()>(f: F) {
651 f(); // this is valid, but f(3) would not work
657 The built-in function traits are generic over a tuple of the function arguments.
658 If one uses angle-bracket notation (`Fn<(T,), Output=U>`) instead of parentheses
659 (`Fn(T) -> U`) to denote the function trait, the type parameter should be a
660 tuple. Otherwise function call notation cannot be used and the trait will not be
661 implemented by closures.
663 The most likely source of this error is using angle-bracket notation without
664 wrapping the function argument type into a tuple, for example:
667 fn foo<F: Fn<i32>>(f: F) -> F::Output { f(3) }
670 It can be fixed by adjusting the trait bound like this:
673 fn foo<F: Fn<(i32,)>>(f: F) -> F::Output { f(3) }
676 Note that `(T,)` always denotes the type of a 1-tuple containing an element of
677 type `T`. The comma is necessary for syntactic disambiguation.
681 External C functions are allowed to be variadic. However, a variadic function
682 takes a minimum number of arguments. For example, consider C's variadic `printf`
687 use libc::{ c_char, c_int };
690 fn printf(_: *const c_char, ...) -> c_int;
694 Using this declaration, it must be called with at least one argument, so
695 simply calling `printf()` is invalid. But the following uses are allowed:
699 use std::ffi::CString;
701 printf(CString::new("test\n").unwrap().as_ptr());
702 printf(CString::new("number = %d\n").unwrap().as_ptr(), 3);
703 printf(CString::new("%d, %d\n").unwrap().as_ptr(), 10, 5);
709 The number of arguments passed to a function must match the number of arguments
710 specified in the function signature.
712 For example, a function like:
715 fn f(a: u16, b: &str) {}
718 Must always be called with exactly two arguments, e.g. `f(2, "test")`.
720 Note that Rust does not have a notion of optional function arguments or
721 variadic functions (except for its C-FFI).
725 This error indicates that during an attempt to build a struct or struct-like
726 enum variant, one of the fields was specified more than once. Erroneous code
737 x: 0, // error: field `x` specified more than once
742 Each field should be specified exactly one time. Example:
750 let x = Foo { x: 0 }; // ok!
756 This error indicates that during an attempt to build a struct or struct-like
757 enum variant, one of the fields was not provided. Erroneous code example:
766 let x = Foo { x: 0 }; // error: missing field: `y`
770 Each field should be specified exactly once. Example:
779 let x = Foo { x: 0, y: 0 }; // ok!
785 Box placement expressions (like C++'s "placement new") do not yet support any
786 place expression except the exchange heap (i.e. `std::boxed::HEAP`).
787 Furthermore, the syntax is changing to use `in` instead of `box`. See [RFC 470]
788 and [RFC 809] for more details.
790 [RFC 470]: https://github.com/rust-lang/rfcs/pull/470
791 [RFC 809]: https://github.com/rust-lang/rfcs/pull/809
795 The left-hand side of a compound assignment expression must be an lvalue
796 expression. An lvalue expression represents a memory location and includes
797 item paths (ie, namespaced variables), dereferences, indexing expressions,
798 and field references.
800 Let's start with some erroneous code examples:
803 use std::collections::LinkedList;
805 // Bad: assignment to non-lvalue expression
806 LinkedList::new() += 1;
810 fn some_func(i: &mut i32) {
811 i += 12; // Error : '+=' operation cannot be applied on a reference !
815 And now some working examples:
824 fn some_func(i: &mut i32) {
831 The compiler found a function whose body contains a `return;` statement but
832 whose return type is not `()`. An example of this is:
841 Since `return;` is just like `return ();`, there is a mismatch between the
842 function's return type and the value being returned.
846 The left-hand side of an assignment operator must be an lvalue expression. An
847 lvalue expression represents a memory location and can be a variable (with
848 optional namespacing), a dereference, an indexing expression or a field
851 More details can be found here:
852 https://doc.rust-lang.org/reference.html#lvalues-rvalues-and-temporaries
854 Now, we can go further. Here are some erroneous code examples:
862 const SOME_CONST : i32 = 12;
864 fn some_other_func() {}
867 SOME_CONST = 14; // error : a constant value cannot be changed!
868 1 = 3; // error : 1 isn't a valid lvalue!
869 some_other_func() = 4; // error : we can't assign value to a function!
870 SomeStruct.x = 12; // error : SomeStruct a structure name but it is used
875 And now let's give working examples:
882 let mut s = SomeStruct {x: 0, y: 0};
884 s.x = 3; // that's good !
888 fn some_func(x: &mut i32) {
889 *x = 12; // that's good !
895 You tried to use structure-literal syntax to create an item that is
896 not a struct-style structure or enum variant.
898 Example of erroneous code:
901 enum Foo { FirstValue(i32) };
903 let u = Foo::FirstValue { value: 0 }; // error: Foo::FirstValue
904 // isn't a structure!
905 // or even simpler, if the name doesn't refer to a structure at all.
906 let t = u32 { value: 4 }; // error: `u32` does not name a structure.
909 To fix this, ensure that the name was correctly spelled, and that
910 the correct form of initializer was used.
912 For example, the code above can be fixed to:
920 let u = Foo::FirstValue(0i32);
928 You cannot define a struct (or enum) `Foo` that requires an instance of `Foo`
929 in order to make a new `Foo` value. This is because there would be no way a
930 first instance of `Foo` could be made to initialize another instance!
932 Here's an example of a struct that has this problem:
935 struct Foo { x: Box<Foo> } // error
938 One fix is to use `Option`, like so:
941 struct Foo { x: Option<Box<Foo>> }
944 Now it's possible to create at least one instance of `Foo`: `Foo { x: None }`.
948 When using the `#[simd]` attribute on a tuple struct, the components of the
949 tuple struct must all be of a concrete, nongeneric type so the compiler can
950 reason about how to use SIMD with them. This error will occur if the types
953 This will cause an error:
956 #![feature(repr_simd)]
959 struct Bad<T>(T, T, T);
965 #![feature(repr_simd)]
968 struct Good(u32, u32, u32);
973 The `#[simd]` attribute can only be applied to non empty tuple structs, because
974 it doesn't make sense to try to use SIMD operations when there are no values to
977 This will cause an error:
980 #![feature(repr_simd)]
989 #![feature(repr_simd)]
997 When using the `#[simd]` attribute to automatically use SIMD operations in tuple
998 struct, the types in the struct must all be of the same type, or the compiler
999 will trigger this error.
1001 This will cause an error:
1004 #![feature(repr_simd)]
1007 struct Bad(u16, u32, u32);
1013 #![feature(repr_simd)]
1016 struct Good(u32, u32, u32);
1021 When using the `#[simd]` attribute on a tuple struct, the elements in the tuple
1022 must be machine types so SIMD operations can be applied to them.
1024 This will cause an error:
1027 #![feature(repr_simd)]
1036 #![feature(repr_simd)]
1039 struct Good(u32, u32, u32);
1044 Enum variants which contain no data can be given a custom integer
1045 representation. This error indicates that the value provided is not an integer
1046 literal and is therefore invalid.
1048 For example, in the following code:
1056 We try to set the representation to a string.
1058 There's no general fix for this; if you can work with an integer then just set
1067 However if you actually wanted a mapping between variants and non-integer
1068 objects, it may be preferable to use a method with a match instead:
1073 fn get_str(&self) -> &'static str {
1083 Enum discriminants are used to differentiate enum variants stored in memory.
1084 This error indicates that the same value was used for two or more variants,
1085 making them impossible to tell apart.
1105 Note that variants without a manually specified discriminant are numbered from
1106 top to bottom starting from 0, so clashes can occur with seemingly unrelated
1116 Here `X` will have already been specified the discriminant 0 by the time `Y` is
1117 encountered, so a conflict occurs.
1121 When you specify enum discriminants with `=`, the compiler expects `isize`
1122 values by default. Or you can add the `repr` attibute to the enum declaration
1123 for an explicit choice of the discriminant type. In either cases, the
1124 discriminant values must fall within a valid range for the expected type;
1125 otherwise this error is raised. For example:
1135 Here, 1024 lies outside the valid range for `u8`, so the discriminant for `A` is
1136 invalid. Here is another, more subtle example which depends on target word size:
1139 enum DependsOnPointerSize {
1144 Here, `1 << 32` is interpreted as an `isize` value. So it is invalid for 32 bit
1145 target (`target_pointer_width = "32"`) but valid for 64 bit target.
1147 You may want to change representation types to fix this, or else change invalid
1148 discriminant values so that they fit within the existing type.
1152 An unsupported representation was attempted on a zero-variant enum.
1154 Erroneous code example:
1158 enum NightsWatch {} // error: unsupported representation for zero-variant enum
1161 It is impossible to define an integer type to be used to represent zero-variant
1162 enum values because there are no zero-variant enum values. There is no way to
1163 construct an instance of the following type using only safe code. So you have
1164 two solutions. Either you add variants in your enum:
1174 or you remove the integer represention of your enum:
1182 Too many type parameters were supplied for a function. For example:
1188 foo::<f64, bool>(); // error, expected 1 parameter, found 2 parameters
1192 The number of supplied parameters must exactly match the number of defined type
1197 You gave too many lifetime parameters. Erroneous code example:
1203 f::<'static>() // error: too many lifetime parameters provided
1207 Please check you give the right number of lifetime parameters. Example:
1217 It's also important to note that the Rust compiler can generally
1218 determine the lifetime by itself. Example:
1226 // it can be written like this
1227 fn get_value<'a>(&'a self) -> &'a str { &self.value }
1228 // but the compiler works fine with this too:
1229 fn without_lifetime(&self) -> &str { &self.value }
1233 let f = Foo { value: "hello".to_owned() };
1235 println!("{}", f.get_value());
1236 println!("{}", f.without_lifetime());
1242 Not enough type parameters were supplied for a function. For example:
1248 foo::<f64>(); // error, expected 2 parameters, found 1 parameter
1252 Note that if a function takes multiple type parameters but you want the compiler
1253 to infer some of them, you can use type placeholders:
1256 fn foo<T, U>(x: T) {}
1260 foo::<f64>(x); // error, expected 2 parameters, found 1 parameter
1261 foo::<_, f64>(x); // same as `foo::<bool, f64>(x)`
1267 You gave an unnecessary type parameter in a type alias. Erroneous code
1271 type Foo<T> = u32; // error: type parameter `T` is unused
1273 type Foo<A,B> = Box<A>; // error: type parameter `B` is unused
1276 Please check you didn't write too many type parameters. Example:
1279 type Foo = u32; // ok!
1280 type Foo2<A> = Box<A>; // ok!
1285 You tried to declare an undefined atomic operation function.
1286 Erroneous code example:
1289 #![feature(intrinsics)]
1291 extern "rust-intrinsic" {
1292 fn atomic_foo(); // error: unrecognized atomic operation
1297 Please check you didn't make a mistake in the function's name. All intrinsic
1298 functions are defined in librustc_trans/trans/intrinsic.rs and in
1299 libcore/intrinsics.rs in the Rust source code. Example:
1302 #![feature(intrinsics)]
1304 extern "rust-intrinsic" {
1305 fn atomic_fence(); // ok!
1311 You declared an unknown intrinsic function. Erroneous code example:
1314 #![feature(intrinsics)]
1316 extern "rust-intrinsic" {
1317 fn foo(); // error: unrecognized intrinsic function: `foo`
1327 Please check you didn't make a mistake in the function's name. All intrinsic
1328 functions are defined in librustc_trans/trans/intrinsic.rs and in
1329 libcore/intrinsics.rs in the Rust source code. Example:
1332 #![feature(intrinsics)]
1334 extern "rust-intrinsic" {
1335 fn atomic_fence(); // ok!
1347 You gave an invalid number of type parameters to an intrinsic function.
1348 Erroneous code example:
1351 #![feature(intrinsics)]
1353 extern "rust-intrinsic" {
1354 fn size_of<T, U>() -> usize; // error: intrinsic has wrong number
1355 // of type parameters
1359 Please check that you provided the right number of lifetime parameters
1360 and verify with the function declaration in the Rust source code.
1364 #![feature(intrinsics)]
1366 extern "rust-intrinsic" {
1367 fn size_of<T>() -> usize; // ok!
1373 You hit this error because the compiler lacks the information to
1374 determine a type for this expression. Erroneous code example:
1378 let x = |_| {}; // error: cannot determine a type for this expression
1382 You have two possibilities to solve this situation:
1383 * Give an explicit definition of the expression
1384 * Infer the expression
1390 let x = |_ : u32| {}; // ok!
1399 You hit this error because the compiler lacks the information to
1400 determine the type of this variable. Erroneous code example:
1404 // could be an array of anything
1405 let x = []; // error: cannot determine a type for this local variable
1409 To solve this situation, constrain the type of the variable.
1413 #![allow(unused_variables)]
1416 let x: [u8; 0] = [];
1422 This error indicates that a lifetime is missing from a type. If it is an error
1423 inside a function signature, the problem may be with failing to adhere to the
1424 lifetime elision rules (see below).
1426 Here are some simple examples of where you'll run into this error:
1429 struct Foo { x: &bool } // error
1430 struct Foo<'a> { x: &'a bool } // correct
1432 enum Bar { A(u8), B(&bool), } // error
1433 enum Bar<'a> { A(u8), B(&'a bool), } // correct
1435 type MyStr = &str; // error
1436 type MyStr<'a> = &'a str; // correct
1439 Lifetime elision is a special, limited kind of inference for lifetimes in
1440 function signatures which allows you to leave out lifetimes in certain cases.
1441 For more background on lifetime elision see [the book][book-le].
1443 The lifetime elision rules require that any function signature with an elided
1444 output lifetime must either have
1446 - exactly one input lifetime
1447 - or, multiple input lifetimes, but the function must also be a method with a
1448 `&self` or `&mut self` receiver
1450 In the first case, the output lifetime is inferred to be the same as the unique
1451 input lifetime. In the second case, the lifetime is instead inferred to be the
1452 same as the lifetime on `&self` or `&mut self`.
1454 Here are some examples of elision errors:
1457 // error, no input lifetimes
1458 fn foo() -> &str { }
1460 // error, `x` and `y` have distinct lifetimes inferred
1461 fn bar(x: &str, y: &str) -> &str { }
1463 // error, `y`'s lifetime is inferred to be distinct from `x`'s
1464 fn baz<'a>(x: &'a str, y: &str) -> &str { }
1467 [book-le]: https://doc.rust-lang.org/nightly/book/lifetimes.html#lifetime-elision
1471 This error means that an incorrect number of lifetime parameters were provided
1472 for a type (like a struct or enum) or trait.
1474 Some basic examples include:
1477 struct Foo<'a>(&'a str);
1478 enum Bar { A, B, C }
1481 foo: Foo, // error: expected 1, found 0
1482 bar: Bar<'a>, // error: expected 0, found 1
1486 Here's an example that is currently an error, but may work in a future version
1490 struct Foo<'a>(&'a str);
1493 impl Quux for Foo { } // error: expected 1, found 0
1496 Lifetime elision in implementation headers was part of the lifetime elision
1497 RFC. It is, however, [currently unimplemented][iss15872].
1499 [iss15872]: https://github.com/rust-lang/rust/issues/15872
1503 You can only define an inherent implementation for a type in the same crate
1504 where the type was defined. For example, an `impl` block as below is not allowed
1505 since `Vec` is defined in the standard library:
1508 impl Vec<u8> { } // error
1511 To fix this problem, you can do either of these things:
1513 - define a trait that has the desired associated functions/types/constants and
1514 implement the trait for the type in question
1515 - define a new type wrapping the type and define an implementation on the new
1518 Note that using the `type` keyword does not work here because `type` only
1519 introduces a type alias:
1522 type Bytes = Vec<u8>;
1524 impl Bytes { } // error, same as above
1529 This error indicates a violation of one of Rust's orphan rules for trait
1530 implementations. The rule prohibits any implementation of a foreign trait (a
1531 trait defined in another crate) where
1533 - the type that is implementing the trait is foreign
1534 - all of the parameters being passed to the trait (if there are any) are also
1537 Here's one example of this error:
1540 impl Drop for u32 {}
1543 To avoid this kind of error, ensure that at least one local type is referenced
1547 pub struct Foo; // you define your type in your crate
1549 impl Drop for Foo { // and you can implement the trait on it!
1550 // code of trait implementation here
1553 impl From<Foo> for i32 { // or you use a type from your crate as
1555 fn from(i: Foo) -> i32 {
1561 Alternatively, define a trait locally and implement that instead:
1565 fn get(&self) -> usize;
1569 fn get(&self) -> usize { 0 }
1573 For information on the design of the orphan rules, see [RFC 1023].
1575 [RFC 1023]: https://github.com/rust-lang/rfcs/pull/1023
1579 You're trying to write an inherent implementation for something which isn't a
1580 struct nor an enum. Erroneous code example:
1583 impl (u8, u8) { // error: no base type found for inherent implementation
1584 fn get_state(&self) -> String {
1590 To fix this error, please implement a trait on the type or wrap it in a struct.
1594 // we create a trait here
1595 trait LiveLongAndProsper {
1596 fn get_state(&self) -> String;
1599 // and now you can implement it on (u8, u8)
1600 impl LiveLongAndProsper for (u8, u8) {
1601 fn get_state(&self) -> String {
1602 "He's dead, Jim!".to_owned()
1607 Alternatively, you can create a newtype. A newtype is a wrapping tuple-struct.
1608 For example, `NewType` is a newtype over `Foo` in `struct NewType(Foo)`.
1612 struct TypeWrapper((u8, u8));
1615 fn get_state(&self) -> String {
1616 "Fascinating!".to_owned()
1623 There are conflicting trait implementations for the same type.
1624 Example of erroneous code:
1628 fn get(&self) -> usize;
1631 impl<T> MyTrait for T {
1632 fn get(&self) -> usize { 0 }
1639 impl MyTrait for Foo { // error: conflicting implementations of trait
1640 // `MyTrait` for type `Foo`
1641 fn get(&self) -> usize { self.value }
1645 When looking for the implementation for the trait, the compiler finds
1646 both the `impl<T> MyTrait for T` where T is all types and the `impl
1647 MyTrait for Foo`. Since a trait cannot be implemented multiple times,
1648 this is an error. So, when you write:
1652 fn get(&self) -> usize;
1655 impl<T> MyTrait for T {
1656 fn get(&self) -> usize { 0 }
1660 This makes the trait implemented on all types in the scope. So if you
1661 try to implement it on another one after that, the implementations will
1666 fn get(&self) -> usize;
1669 impl<T> MyTrait for T {
1670 fn get(&self) -> usize { 0 }
1678 f.get(); // the trait is implemented so we can use it
1684 An attempt was made to implement Drop on a trait, which is not allowed: only
1685 structs and enums can implement Drop. An example causing this error:
1690 impl Drop for MyTrait {
1691 fn drop(&mut self) {}
1695 A workaround for this problem is to wrap the trait up in a struct, and implement
1696 Drop on that. An example is shown below:
1700 struct MyWrapper<T: MyTrait> { foo: T }
1702 impl <T: MyTrait> Drop for MyWrapper<T> {
1703 fn drop(&mut self) {}
1708 Alternatively, wrapping trait objects requires something like the following:
1713 //or Box<MyTrait>, if you wanted an owned trait object
1714 struct MyWrapper<'a> { foo: &'a MyTrait }
1716 impl <'a> Drop for MyWrapper<'a> {
1717 fn drop(&mut self) {}
1723 In order to be consistent with Rust's lack of global type inference, type
1724 placeholders are disallowed by design in item signatures.
1726 Examples of this error include:
1729 fn foo() -> _ { 5 } // error, explicitly write out the return type instead
1731 static BAR: _ = "test"; // error, explicitly write out the type instead
1736 An attempt was made to add a generic constraint to a type alias. While Rust will
1737 allow this with a warning, it will not currently enforce the constraint.
1738 Consider the example below:
1743 type MyType<R: Foo> = (R, ());
1750 We're able to declare a variable of type `MyType<u32>`, despite the fact that
1751 `u32` does not implement `Foo`. As a result, one should avoid using generic
1752 constraints in concert with type aliases.
1756 You declared two fields of a struct with the same name. Erroneous code
1762 field1: i32, // error: field is already declared
1766 Please verify that the field names have been correctly spelled. Example:
1777 Type parameter defaults can only use parameters that occur before them.
1778 Erroneous code example:
1781 struct Foo<T=U, U=()> {
1785 // error: type parameters with a default cannot use forward declared
1789 Since type parameters are evaluated in-order, you may be able to fix this issue
1793 struct Foo<U=(), T=U> {
1799 Please also verify that this wasn't because of a name-clash and rename the type
1804 It is not possible to define `main` with type parameters, or even with function
1805 parameters. When `main` is present, it must take no arguments and return `()`.
1806 Erroneous code example:
1809 fn main<T>() { // error: main function is not allowed to have type parameters
1815 A function with the `start` attribute was declared with type parameters.
1817 Erroneous code example:
1826 It is not possible to declare type parameters on a function that has the `start`
1827 attribute. Such a function must have the following type signature (for more
1828 information: http://doc.rust-lang.org/stable/book/no-stdlib.html):
1831 fn(isize, *const *const u8) -> isize;
1840 fn my_start(argc: isize, argv: *const *const u8) -> isize {
1847 This error means that an attempt was made to match a struct type enum
1848 variant as a non-struct type:
1851 enum Foo { B { i: u32 } }
1853 fn bar(foo: Foo) -> u32 {
1855 Foo::B(i) => i, // error E0164
1860 Try using `{}` instead:
1863 enum Foo { B { i: u32 } }
1865 fn bar(foo: Foo) -> u32 {
1874 This error means that the compiler found a return expression in a function
1875 marked as diverging. A function diverges if it has `!` in the place of the
1876 return type in its signature. For example:
1879 fn foo() -> ! { return; } // error
1882 For a function that diverges, every control path in the function must never
1883 return, for example with a `loop` that never breaks or a call to another
1884 diverging function (such as `panic!()`).
1888 This error means that an attempt was made to specify the type of a variable with
1889 a combination of a concrete type and a trait. Consider the following example:
1892 fn foo(bar: i32+std::fmt::Display) {}
1895 The code is trying to specify that we want to receive a signed 32-bit integer
1896 which also implements `Display`. This doesn't make sense: when we pass `i32`, a
1897 concrete type, it implicitly includes all of the traits that it implements.
1898 This includes `Display`, `Debug`, `Clone`, and a host of others.
1900 If `i32` implements the trait we desire, there's no need to specify the trait
1901 separately. If it does not, then we need to `impl` the trait for `i32` before
1902 passing it into `foo`. Either way, a fixed definition for `foo` will look like
1909 To learn more about traits, take a look at the Book:
1911 https://doc.rust-lang.org/book/traits.html
1915 In types, the `+` type operator has low precedence, so it is often necessary
1924 w: &'a Foo + Copy, // error, use &'a (Foo + Copy)
1925 x: &'a Foo + 'a, // error, use &'a (Foo + 'a)
1926 y: &'a mut Foo + 'a, // error, use &'a mut (Foo + 'a)
1927 z: fn() -> Foo + 'a, // error, use fn() -> (Foo + 'a)
1931 More details can be found in [RFC 438].
1933 [RFC 438]: https://github.com/rust-lang/rfcs/pull/438
1937 Explicitly implementing both Drop and Copy for a type is currently disallowed.
1938 This feature can make some sense in theory, but the current implementation is
1939 incorrect and can lead to memory unsafety (see [issue #20126][iss20126]), so
1940 it has been disabled for now.
1942 [iss20126]: https://github.com/rust-lang/rust/issues/20126
1946 An associated function for a trait was defined to be static, but an
1947 implementation of the trait declared the same function to be a method (i.e. to
1948 take a `self` parameter).
1950 Here's an example of this error:
1960 // error, method `foo` has a `&self` declaration in the impl, but not in
1968 An associated function for a trait was defined to be a method (i.e. to take a
1969 `self` parameter), but an implementation of the trait declared the same function
1972 Here's an example of this error:
1982 // error, method `foo` has a `&self` declaration in the trait, but not in
1990 Trait objects need to have all associated types specified. Erroneous code
1998 type Foo = Trait; // error: the value of the associated type `Bar` (from
1999 // the trait `Trait`) must be specified
2002 Please verify you specified all associated types of the trait and that you
2003 used the right trait. Example:
2010 type Foo = Trait<Bar=i32>; // ok!
2015 Negative impls are only allowed for traits with default impls. For more
2016 information see the [opt-in builtin traits RFC](https://github.com/rust-lang/
2017 rfcs/blob/master/text/0019-opt-in-builtin-traits.md).
2021 `where` clauses must use generic type parameters: it does not make sense to use
2022 them otherwise. An example causing this error:
2029 #[derive(Copy,Clone)]
2034 impl Foo for Wrapper<u32> where Wrapper<u32>: Clone {
2039 This use of a `where` clause is strange - a more common usage would look
2040 something like the following:
2047 #[derive(Copy,Clone)]
2051 impl <T> Foo for Wrapper<T> where Wrapper<T>: Clone {
2056 Here, we're saying that the implementation exists on Wrapper only when the
2057 wrapped type `T` implements `Clone`. The `where` clause is important because
2058 some types will not implement `Clone`, and thus will not get this method.
2060 In our erroneous example, however, we're referencing a single concrete type.
2061 Since we know for certain that `Wrapper<u32>` implements `Clone`, there's no
2062 reason to also specify it in a `where` clause.
2066 A type parameter was declared which shadows an existing one. An example of this
2071 fn do_something(&self) -> T;
2072 fn do_something_else<T: Clone>(&self, bar: T);
2076 In this example, the trait `Foo` and the trait method `do_something_else` both
2077 define a type parameter `T`. This is not allowed: if the method wishes to
2078 define a type parameter, it must use a different name for it.
2082 Your method's lifetime parameters do not match the trait declaration.
2083 Erroneous code example:
2087 fn bar<'a,'b:'a>(x: &'a str, y: &'b str);
2092 impl Trait for Foo {
2093 fn bar<'a,'b>(x: &'a str, y: &'b str) {
2094 // error: lifetime parameters or bounds on method `bar`
2095 // do not match the trait declaration
2100 The lifetime constraint `'b` for bar() implementation does not match the
2101 trait declaration. Ensure lifetime declarations match exactly in both trait
2102 declaration and implementation. Example:
2106 fn t<'a,'b:'a>(x: &'a str, y: &'b str);
2111 impl Trait for Foo {
2112 fn t<'a,'b:'a>(x: &'a str, y: &'b str) { // ok!
2119 Inherent implementations (one that do not implement a trait but provide
2120 methods associated with a type) are always safe because they are not
2121 implementing an unsafe trait. Removing the `unsafe` keyword from the inherent
2122 implementation will resolve this error.
2127 // this will cause this error
2129 // converting it to this will fix it
2135 A negative implementation is one that excludes a type from implementing a
2136 particular trait. Not being able to use a trait is always a safe operation,
2137 so negative implementations are always safe and never need to be marked as
2141 #![feature(optin_builtin_traits)]
2145 // unsafe is unnecessary
2146 unsafe impl !Clone for Foo { }
2152 #![feature(optin_builtin_traits)]
2158 impl Enterprise for .. { }
2160 impl !Enterprise for Foo { }
2163 Please note that negative impls are only allowed for traits with default impls.
2167 Safe traits should not have unsafe implementations, therefore marking an
2168 implementation for a safe trait unsafe will cause a compiler error. Removing
2169 the unsafe marker on the trait noted in the error will resolve this problem.
2176 // this won't compile because Bar is safe
2177 unsafe impl Bar for Foo { }
2178 // this will compile
2179 impl Bar for Foo { }
2184 Unsafe traits must have unsafe implementations. This error occurs when an
2185 implementation for an unsafe trait isn't marked as unsafe. This may be resolved
2186 by marking the unsafe implementation as unsafe.
2191 unsafe trait Bar { }
2193 // this won't compile because Bar is unsafe and impl isn't unsafe
2194 impl Bar for Foo { }
2195 // this will compile
2196 unsafe impl Bar for Foo { }
2201 It is an error to define two associated items (like methods, associated types,
2202 associated functions, etc.) with the same identifier.
2210 fn bar(&self) -> bool { self.0 > 5 }
2211 fn bar() {} // error: duplicate associated function
2216 fn baz(&self) -> bool;
2222 fn baz(&self) -> bool { true }
2224 // error: duplicate method
2225 fn baz(&self) -> bool { self.0 > 5 }
2227 // error: duplicate associated type
2232 Note, however, that items with the same name are allowed for inherent `impl`
2233 blocks that don't overlap:
2239 fn bar(&self) -> bool { self.0 > 5 }
2243 fn bar(&self) -> bool { self.0 }
2249 Inherent associated types were part of [RFC 195] but are not yet implemented.
2250 See [the tracking issue][iss8995] for the status of this implementation.
2252 [RFC 195]: https://github.com/rust-lang/rfcs/pull/195
2253 [iss8995]: https://github.com/rust-lang/rust/issues/8995
2257 An attempt to implement the `Copy` trait for a struct failed because one of the
2258 fields does not implement `Copy`. To fix this, you must implement `Copy` for the
2259 mentioned field. Note that this may not be possible, as in the example of
2266 impl Copy for Foo { }
2269 This fails because `Vec<T>` does not implement `Copy` for any `T`.
2271 Here's another example that will fail:
2280 This fails because `&mut T` is not `Copy`, even when `T` is `Copy` (this
2281 differs from the behavior for `&T`, which is always `Copy`).
2285 An attempt to implement the `Copy` trait for an enum failed because one of the
2286 variants does not implement `Copy`. To fix this, you must implement `Copy` for
2287 the mentioned variant. Note that this may not be possible, as in the example of
2295 impl Copy for Foo { }
2298 This fails because `Vec<T>` does not implement `Copy` for any `T`.
2300 Here's another example that will fail:
2310 This fails because `&mut T` is not `Copy`, even when `T` is `Copy` (this
2311 differs from the behavior for `&T`, which is always `Copy`).
2315 You can only implement `Copy` for a struct or enum. Both of the following
2316 examples will fail, because neither `i32` (primitive type) nor `&'static Bar`
2317 (reference to `Bar`) is a struct or enum:
2321 impl Copy for Foo { } // error
2323 #[derive(Copy, Clone)]
2325 impl Copy for &'static Bar { } // error
2330 Any type parameter or lifetime parameter of an `impl` must meet at least one of
2331 the following criteria:
2333 - it appears in the self type of the impl
2334 - for a trait impl, it appears in the trait reference
2335 - it is bound as an associated type
2339 Suppose we have a struct `Foo` and we would like to define some methods for it.
2340 The following definition leads to a compiler error:
2345 impl<T: Default> Foo {
2346 // error: the type parameter `T` is not constrained by the impl trait, self
2347 // type, or predicates [E0207]
2348 fn get(&self) -> T {
2349 <T as Default>::default()
2354 The problem is that the parameter `T` does not appear in the self type (`Foo`)
2355 of the impl. In this case, we can fix the error by moving the type parameter
2356 from the `impl` to the method `get`:
2362 // Move the type parameter from the impl to the method
2364 fn get<T: Default>(&self) -> T {
2365 <T as Default>::default()
2372 As another example, suppose we have a `Maker` trait and want to establish a
2373 type `FooMaker` that makes `Foo`s:
2378 fn make(&mut self) -> Self::Item;
2387 impl<T: Default> Maker for FooMaker {
2388 // error: the type parameter `T` is not constrained by the impl trait, self
2389 // type, or predicates [E0207]
2392 fn make(&mut self) -> Foo<T> {
2393 Foo { foo: <T as Default>::default() }
2398 This fails to compile because `T` does not appear in the trait or in the
2401 One way to work around this is to introduce a phantom type parameter into
2402 `FooMaker`, like so:
2405 use std::marker::PhantomData;
2409 fn make(&mut self) -> Self::Item;
2416 // Add a type parameter to `FooMaker`
2417 struct FooMaker<T> {
2418 phantom: PhantomData<T>,
2421 impl<T: Default> Maker for FooMaker<T> {
2424 fn make(&mut self) -> Foo<T> {
2426 foo: <T as Default>::default(),
2432 Another way is to do away with the associated type in `Maker` and use an input
2433 type parameter instead:
2436 // Use a type parameter instead of an associated type here
2438 fn make(&mut self) -> Item;
2447 impl<T: Default> Maker<Foo<T>> for FooMaker {
2448 fn make(&mut self) -> Foo<T> {
2449 Foo { foo: <T as Default>::default() }
2454 ### Additional information
2456 For more information, please see [RFC 447].
2458 [RFC 447]: https://github.com/rust-lang/rfcs/blob/master/text/0447-no-unused-impl-parameters.md
2462 This error indicates a violation of one of Rust's orphan rules for trait
2463 implementations. The rule concerns the use of type parameters in an
2464 implementation of a foreign trait (a trait defined in another crate), and
2465 states that type parameters must be "covered" by a local type. To understand
2466 what this means, it is perhaps easiest to consider a few examples.
2468 If `ForeignTrait` is a trait defined in some external crate `foo`, then the
2469 following trait `impl` is an error:
2473 use foo::ForeignTrait;
2475 impl<T> ForeignTrait for T { } // error
2478 To work around this, it can be covered with a local type, `MyType`:
2481 struct MyType<T>(T);
2482 impl<T> ForeignTrait for MyType<T> { } // Ok
2485 Please note that a type alias is not sufficient.
2487 For another example of an error, suppose there's another trait defined in `foo`
2488 named `ForeignTrait2` that takes two type parameters. Then this `impl` results
2489 in the same rule violation:
2493 impl<T> ForeignTrait2<T, MyType<T>> for MyType2 { } // error
2496 The reason for this is that there are two appearances of type parameter `T` in
2497 the `impl` header, both as parameters for `ForeignTrait2`. The first appearance
2498 is uncovered, and so runs afoul of the orphan rule.
2500 Consider one more example:
2503 impl<T> ForeignTrait2<MyType<T>, T> for MyType2 { } // Ok
2506 This only differs from the previous `impl` in that the parameters `T` and
2507 `MyType<T>` for `ForeignTrait2` have been swapped. This example does *not*
2508 violate the orphan rule; it is permitted.
2510 To see why that last example was allowed, you need to understand the general
2511 rule. Unfortunately this rule is a bit tricky to state. Consider an `impl`:
2514 impl<P1, ..., Pm> ForeignTrait<T1, ..., Tn> for T0 { ... }
2517 where `P1, ..., Pm` are the type parameters of the `impl` and `T0, ..., Tn`
2518 are types. One of the types `T0, ..., Tn` must be a local type (this is another
2519 orphan rule, see the explanation for E0117). Let `i` be the smallest integer
2520 such that `Ti` is a local type. Then no type parameter can appear in any of the
2523 For information on the design of the orphan rules, see [RFC 1023].
2525 [RFC 1023]: https://github.com/rust-lang/rfcs/pull/1023
2530 You used a function or type which doesn't fit the requirements for where it was
2531 used. Erroneous code examples:
2534 #![feature(intrinsics)]
2536 extern "rust-intrinsic" {
2537 fn size_of<T>(); // error: intrinsic has wrong type
2542 fn main() -> i32 { 0 }
2543 // error: main function expects type: `fn() {main}`: expected (), found i32
2550 // error: mismatched types in range: expected u8, found i8
2560 fn x(self: Rc<Foo>) {}
2561 // error: mismatched self type: expected `Foo`: expected struct
2562 // `Foo`, found struct `alloc::rc::Rc`
2566 For the first code example, please check the function definition. Example:
2569 #![feature(intrinsics)]
2571 extern "rust-intrinsic" {
2572 fn size_of<T>() -> usize; // ok!
2576 The second case example is a bit particular : the main function must always
2577 have this definition:
2583 They never take parameters and never return types.
2585 For the third example, when you match, all patterns must have the same type
2586 as the type you're matching on. Example:
2592 0u8...3u8 => (), // ok!
2597 And finally, for the last example, only `Box<Self>`, `&Self`, `Self`,
2598 or `&mut Self` work as explicit self parameters. Example:
2604 fn x(self: Box<Foo>) {} // ok!
2611 A generic type was described using parentheses rather than angle brackets. For
2616 let v: Vec(&str) = vec!["foo"];
2620 This is not currently supported: `v` should be defined as `Vec<&str>`.
2621 Parentheses are currently only used with generic types when defining parameters
2622 for `Fn`-family traits.
2626 You used an associated type which isn't defined in the trait.
2627 Erroneous code example:
2634 type Foo = T1<F=i32>; // error: associated type `F` not found for `T1`
2641 // error: Baz is used but not declared
2642 fn return_bool(&self, &Self::Bar, &Self::Baz) -> bool;
2646 Make sure that you have defined the associated type in the trait body.
2647 Also, verify that you used the right trait or you didn't misspell the
2648 associated type name. Example:
2655 type Foo = T1<Bar=i32>; // ok!
2661 type Baz; // we declare `Baz` in our trait.
2663 // and now we can use it here:
2664 fn return_bool(&self, &Self::Bar, &Self::Baz) -> bool;
2670 An attempt was made to retrieve an associated type, but the type was ambiguous.
2689 In this example, `Foo` defines an associated type `A`. `Bar` inherits that type
2690 from `Foo`, and defines another associated type of the same name. As a result,
2691 when we attempt to use `Self::A`, it's ambiguous whether we mean the `A` defined
2692 by `Foo` or the one defined by `Bar`.
2694 There are two options to work around this issue. The first is simply to rename
2695 one of the types. Alternatively, one can specify the intended type using the
2709 let _: <Self as Bar>::A;
2716 An attempt was made to retrieve an associated type, but the type was ambiguous.
2720 trait MyTrait {type X; }
2723 let foo: MyTrait::X;
2727 The problem here is that we're attempting to take the type of X from MyTrait.
2728 Unfortunately, the type of X is not defined, because it's only made concrete in
2729 implementations of the trait. A working version of this code might look like:
2732 trait MyTrait {type X; }
2735 impl MyTrait for MyStruct {
2740 let foo: <MyStruct as MyTrait>::X;
2744 This syntax specifies that we want the X type from MyTrait, as made concrete in
2745 MyStruct. The reason that we cannot simply use `MyStruct::X` is that MyStruct
2746 might implement two different traits with identically-named associated types.
2747 This syntax allows disambiguation between the two.
2751 You attempted to use multiple types as bounds for a closure or trait object.
2752 Rust does not currently support this. A simple example that causes this error:
2756 let _: Box<std::io::Read + std::io::Write>;
2760 Builtin traits are an exception to this rule: it's possible to have bounds of
2761 one non-builtin type, plus any number of builtin types. For example, the
2762 following compiles correctly:
2766 let _: Box<std::io::Read + Send + Sync>;
2772 The attribute must have a value. Erroneous code example:
2775 #![feature(on_unimplemented)]
2777 #[rustc_on_unimplemented] // error: this attribute must have a value
2781 Please supply the missing value of the attribute. Example:
2784 #![feature(on_unimplemented)]
2786 #[rustc_on_unimplemented = "foo"] // ok!
2792 This error indicates that not enough type parameters were found in a type or
2795 For example, the `Foo` struct below is defined to be generic in `T`, but the
2796 type parameter is missing in the definition of `Bar`:
2799 struct Foo<T> { x: T }
2801 struct Bar { x: Foo }
2806 This error indicates that too many type parameters were found in a type or
2809 For example, the `Foo` struct below has no type parameters, but is supplied
2810 with two in the definition of `Bar`:
2813 struct Foo { x: bool }
2815 struct Bar<S, T> { x: Foo<S, T> }
2820 This error indicates an attempt to use a value where a type is expected. For
2828 fn do_something(x: Foo::Bar) { }
2831 In this example, we're attempting to take a type of `Foo::Bar` in the
2832 do_something function. This is not legal: `Foo::Bar` is a value of type `Foo`,
2833 not a distinct static type. Likewise, it's not legal to attempt to
2834 `impl Foo::Bar`: instead, you must `impl Foo` and then pattern match to specify
2835 behavior for specific enum variants.
2839 Default impls for a trait must be located in the same crate where the trait was
2840 defined. For more information see the [opt-in builtin traits RFC](https://github
2841 .com/rust-lang/rfcs/blob/master/text/0019-opt-in-builtin-traits.md).
2845 A cross-crate opt-out trait was implemented on something which wasn't a struct
2846 or enum type. Erroneous code example:
2849 #![feature(optin_builtin_traits)]
2853 impl !Sync for Foo {}
2855 unsafe impl Send for &'static Foo {
2856 // error: cross-crate traits with a default impl, like `core::marker::Send`,
2857 // can only be implemented for a struct/enum type, not
2861 Only structs and enums are permitted to impl Send, Sync, and other opt-out
2862 trait, and the struct or enum must be local to the current crate. So, for
2863 example, `unsafe impl Send for Rc<Foo>` is not allowed.
2867 The `Sized` trait is a special trait built-in to the compiler for types with a
2868 constant size known at compile-time. This trait is automatically implemented
2869 for types as needed by the compiler, and it is currently disallowed to
2870 explicitly implement it for a type.
2874 An associated const was implemented when another trait item was expected.
2875 Erroneous code example:
2878 #![feature(associated_consts)]
2888 // error: item `N` is an associated const, which doesn't match its
2889 // trait `<Bar as Foo>`
2893 Please verify that the associated const wasn't misspelled and the correct trait
2894 was implemented. Example:
2904 type N = u32; // ok!
2911 #![feature(associated_consts)]
2920 const N : u32 = 0; // ok!
2926 A method was implemented when another trait item was expected. Erroneous
2940 // error: item `N` is an associated method, which doesn't match its
2941 // trait `<Bar as Foo>`
2945 To fix this error, please verify that the method name wasn't misspelled and
2946 verify that you are indeed implementing the correct trait items. Example:
2949 #![feature(associated_consts)]
2968 An associated type was implemented when another trait item was expected.
2969 Erroneous code example:
2980 // error: item `N` is an associated type, which doesn't match its
2981 // trait `<Bar as Foo>`
2985 Please verify that the associated type name wasn't misspelled and your
2986 implementation corresponds to the trait definition. Example:
2996 type N = u32; // ok!
3003 #![feature(associated_consts)]
3012 const N : u32 = 0; // ok!
3018 The types of any associated constants in a trait implementation must match the
3019 types in the trait definition. This error indicates that there was a mismatch.
3021 Here's an example of this error:
3031 const BAR: u32 = 5; // error, expected bool, found u32
3037 An attempt was made to access an associated constant through either a generic
3038 type parameter or `Self`. This is not supported yet. An example causing this
3039 error is shown below:
3042 #![feature(associated_consts)]
3050 impl Foo for MyStruct {
3051 const BAR: f64 = 0f64;
3054 fn get_bar_bad<F: Foo>(t: F) -> f64 {
3059 Currently, the value of `BAR` for a particular type can only be accessed
3060 through a concrete type, as shown below:
3063 #![feature(associated_consts)]
3071 fn get_bar_good() -> f64 {
3072 <MyStruct as Foo>::BAR
3078 An attempt was made to implement `Drop` on a concrete specialization of a
3079 generic type. An example is shown below:
3086 impl Drop for Foo<u32> {
3087 fn drop(&mut self) {}
3091 This code is not legal: it is not possible to specialize `Drop` to a subset of
3092 implementations of a generic type. One workaround for this is to wrap the
3093 generic type, as shown below:
3105 fn drop(&mut self) {}
3111 An attempt was made to implement `Drop` on a specialization of a generic type.
3112 An example is shown below:
3117 struct MyStruct<T> {
3121 impl<T: Foo> Drop for MyStruct<T> {
3122 fn drop(&mut self) {}
3126 This code is not legal: it is not possible to specialize `Drop` to a subset of
3127 implementations of a generic type. In order for this code to work, `MyStruct`
3128 must also require that `T` implements `Foo`. Alternatively, another option is
3129 to wrap the generic type in another that specializes appropriately:
3134 struct MyStruct<T> {
3138 struct MyStructWrapper<T: Foo> {
3142 impl <T: Foo> Drop for MyStructWrapper<T> {
3143 fn drop(&mut self) {}
3149 This error indicates that a binary assignment operator like `+=` or `^=` was
3150 applied to a type that doesn't support it. For example:
3153 let mut x = 12f32; // error: binary operation `<<` cannot be applied to
3159 To fix this error, please check that this type implements this binary
3163 let mut x = 12u32; // the `u32` type does implement the `ShlAssign` trait
3168 It is also possible to overload most operators for your own type by
3169 implementing the `[OP]Assign` traits from `std::ops`.
3171 Another problem you might be facing is this: suppose you've overloaded the `+`
3172 operator for some type `Foo` by implementing the `std::ops::Add` trait for
3173 `Foo`, but you find that using `+=` does not work, as in this example:
3183 fn add(self, rhs: Foo) -> Foo {
3189 let mut x: Foo = Foo(5);
3190 x += Foo(7); // error, `+= cannot be applied to the type `Foo`
3194 This is because `AddAssign` is not automatically implemented, so you need to
3195 manually implement it for your type.
3199 A binary operation was attempted on a type which doesn't support it.
3200 Erroneous code example:
3203 let x = 12f32; // error: binary operation `<<` cannot be applied to
3209 To fix this error, please check that this type implements this binary
3213 let x = 12u32; // the `u32` type does implement it:
3214 // https://doc.rust-lang.org/stable/std/ops/trait.Shl.html
3219 It is also possible to overload most operators for your own type by
3220 implementing traits from `std::ops`.
3224 The maximum value of an enum was reached, so it cannot be automatically
3225 set in the next enum value. Erroneous code example:
3228 #[deny(overflowing_literals)]
3230 X = 0x7fffffffffffffff,
3231 Y, // error: enum discriminant overflowed on value after
3232 // 9223372036854775807: i64; set explicitly via
3233 // Y = -9223372036854775808 if that is desired outcome
3237 To fix this, please set manually the next enum value or put the enum variant
3238 with the maximum value at the end of the enum. Examples:
3242 X = 0x7fffffffffffffff,
3252 X = 0x7fffffffffffffff,
3258 When `Trait2` is a subtrait of `Trait1` (for example, when `Trait2` has a
3259 definition like `trait Trait2: Trait1 { ... }`), it is not allowed to implement
3260 `Trait1` for `Trait2`. This is because `Trait2` already implements `Trait1` by
3261 definition, so it is not useful to do this.
3266 trait Foo { fn foo(&self) { } }
3270 impl Bar for Baz { } // error, `Baz` implements `Bar` by definition
3271 impl Foo for Baz { } // error, `Baz` implements `Bar` which implements `Foo`
3272 impl Baz for Baz { } // error, `Baz` (trivially) implements `Baz`
3273 impl Baz for Bar { } // Note: This is OK
3278 A struct without a field containing an unsized type cannot implement
3280 [unsized type](https://doc.rust-lang.org/book/unsized-types.html)
3281 is any type that the compiler doesn't know the length or alignment of at
3282 compile time. Any struct containing an unsized type is also unsized.
3284 Example of erroneous code:
3287 #![feature(coerce_unsized)]
3288 use std::ops::CoerceUnsized;
3290 struct Foo<T: ?Sized> {
3294 // error: Struct `Foo` has no unsized fields that need `CoerceUnsized`.
3295 impl<T, U> CoerceUnsized<Foo<U>> for Foo<T>
3296 where T: CoerceUnsized<U> {}
3299 `CoerceUnsized` is used to coerce one struct containing an unsized type
3300 into another struct containing a different unsized type. If the struct
3301 doesn't have any fields of unsized types then you don't need explicit
3302 coercion to get the types you want. To fix this you can either
3303 not try to implement `CoerceUnsized` or you can add a field that is
3304 unsized to the struct.
3309 #![feature(coerce_unsized)]
3310 use std::ops::CoerceUnsized;
3312 // We don't need to impl `CoerceUnsized` here.
3317 // We add the unsized type field to the struct.
3318 struct Bar<T: ?Sized> {
3323 // The struct has an unsized field so we can implement
3324 // `CoerceUnsized` for it.
3325 impl<T, U> CoerceUnsized<Bar<U>> for Bar<T>
3326 where T: CoerceUnsized<U> {}
3329 Note that `CoerceUnsized` is mainly used by smart pointers like `Box`, `Rc`
3330 and `Arc` to be able to mark that they can coerce unsized types that they
3335 A struct with more than one field containing an unsized type cannot implement
3336 `CoerceUnsized`. This only occurs when you are trying to coerce one of the
3337 types in your struct to another type in the struct. In this case we try to
3338 impl `CoerceUnsized` from `T` to `U` which are both types that the struct
3339 takes. An [unsized type](https://doc.rust-lang.org/book/unsized-types.html)
3340 is any type that the compiler doesn't know the length or alignment of at
3341 compile time. Any struct containing an unsized type is also unsized.
3343 Example of erroneous code:
3346 #![feature(coerce_unsized)]
3347 use std::ops::CoerceUnsized;
3349 struct Foo<T: ?Sized, U: ?Sized> {
3355 // error: Struct `Foo` has more than one unsized field.
3356 impl<T, U> CoerceUnsized<Foo<U, T>> for Foo<T, U> {}
3359 `CoerceUnsized` only allows for coercion from a structure with a single
3360 unsized type field to another struct with a single unsized type field.
3361 In fact Rust only allows for a struct to have one unsized type in a struct
3362 and that unsized type must be the last field in the struct. So having two
3363 unsized types in a single struct is not allowed by the compiler. To fix this
3364 use only one field containing an unsized type in the struct and then use
3365 multiple structs to manage each unsized type field you need.
3370 #![feature(coerce_unsized)]
3371 use std::ops::CoerceUnsized;
3373 struct Foo<T: ?Sized> {
3378 impl <T, U> CoerceUnsized<Foo<U>> for Foo<T>
3379 where T: CoerceUnsized<U> {}
3381 fn coerce_foo<T: CoerceUnsized<U>, U>(t: T) -> Foo<U> {
3382 Foo { a: 12i32, b: t } // we use coercion to get the `Foo<U>` type we need
3389 The type you are trying to impl `CoerceUnsized` for is not a struct.
3390 `CoerceUnsized` can only be implemented for a struct. Unsized types are
3391 already able to be coerced without an implementation of `CoerceUnsized`
3392 whereas a struct containing an unsized type needs to know the unsized type
3393 field it's containing is able to be coerced. An
3394 [unsized type](https://doc.rust-lang.org/book/unsized-types.html)
3395 is any type that the compiler doesn't know the length or alignment of at
3396 compile time. Any struct containing an unsized type is also unsized.
3398 Example of erroneous code:
3401 #![feature(coerce_unsized)]
3402 use std::ops::CoerceUnsized;
3404 struct Foo<T: ?Sized> {
3408 // error: The type `U` is not a struct
3409 impl<T, U> CoerceUnsized<U> for Foo<T> {}
3412 The `CoerceUnsized` trait takes a struct type. Make sure the type you are
3413 providing to `CoerceUnsized` is a struct with only the last field containing an
3419 #![feature(coerce_unsized)]
3420 use std::ops::CoerceUnsized;
3426 // The `Foo<U>` is a struct so `CoerceUnsized` can be implemented
3427 impl<T, U> CoerceUnsized<Foo<U>> for Foo<T> where T: CoerceUnsized<U> {}
3430 Note that in Rust, structs can only contain an unsized type if the field
3431 containing the unsized type is the last and only unsized type field in the
3436 Trait methods cannot be declared `const` by design. For more information, see
3439 [RFC 911]: https://github.com/rust-lang/rfcs/pull/911
3443 Default impls are only allowed for traits with no methods or associated items.
3444 For more information see the [opt-in builtin traits RFC](https://github.com/rust
3445 -lang/rfcs/blob/master/text/0019-opt-in-builtin-traits.md).
3449 You tried to implement methods for a primitive type. Erroneous code example:
3457 // error: only a single inherent implementation marked with
3458 // `#[lang = "mut_ptr"]` is allowed for the `*mut T` primitive
3461 This isn't allowed, but using a trait to implement a method is a good solution.
3473 impl Bar for *mut Foo {
3480 This error indicates that some types or traits depend on each other
3481 and therefore cannot be constructed.
3483 The following example contains a circular dependency between two traits:
3486 trait FirstTrait : SecondTrait {
3490 trait SecondTrait : FirstTrait {
3497 This error indicates that a type or lifetime parameter has been declared
3498 but not actually used. Here is an example that demonstrates the error:
3506 If the type parameter was included by mistake, this error can be fixed
3507 by simply removing the type parameter, as shown below:
3515 Alternatively, if the type parameter was intentionally inserted, it must be
3516 used. A simple fix is shown below:
3524 This error may also commonly be found when working with unsafe code. For
3525 example, when using raw pointers one may wish to specify the lifetime for
3526 which the pointed-at data is valid. An initial attempt (below) causes this
3535 We want to express the constraint that Foo should not outlive `'a`, because
3536 the data pointed to by `T` is only valid for that lifetime. The problem is
3537 that there are no actual uses of `'a`. It's possible to work around this
3538 by adding a PhantomData type to the struct, using it to tell the compiler
3539 to act as if the struct contained a borrowed reference `&'a T`:
3542 use std::marker::PhantomData;
3544 struct Foo<'a, T: 'a> {
3546 phantom: PhantomData<&'a T>
3550 PhantomData can also be used to express information about unused type
3551 parameters. You can read more about it in the API documentation:
3553 https://doc.rust-lang.org/std/marker/struct.PhantomData.html
3557 A type parameter which references `Self` in its default value was not specified.
3558 Example of erroneous code:
3563 fn together_we_will_rule_the_galaxy(son: &A) {}
3564 // error: the type parameter `T` must be explicitly specified in an
3565 // object type because its default value `Self` references the
3569 A trait object is defined over a single, fully-defined trait. With a regular
3570 default parameter, this parameter can just be substituted in. However, if the
3571 default parameter is `Self`, the trait changes for each concrete type; i.e.
3572 `i32` will be expected to implement `A<i32>`, `bool` will be expected to
3573 implement `A<bool>`, etc... These types will not share an implementation of a
3574 fully-defined trait; instead they share implementations of a trait with
3575 different parameters substituted in for each implementation. This is
3576 irreconcilable with what we need to make a trait object work, and is thus
3577 disallowed. Making the trait concrete by explicitly specifying the value of the
3578 defaulted parameter will fix this issue. Fixed example:
3583 fn together_we_will_rule_the_galaxy(son: &A<i32>) {} // Ok!
3588 The length of the platform-intrinsic function `simd_shuffle`
3589 wasn't specified. Erroneous code example:
3592 #![feature(platform_intrinsics)]
3594 extern "platform-intrinsic" {
3595 fn simd_shuffle<A,B>(a: A, b: A, c: [u32; 8]) -> B;
3596 // error: invalid `simd_shuffle`, needs length: `simd_shuffle`
3600 The `simd_shuffle` function needs the length of the array passed as
3601 last parameter in its name. Example:
3604 #![feature(platform_intrinsics)]
3606 extern "platform-intrinsic" {
3607 fn simd_shuffle8<A,B>(a: A, b: A, c: [u32; 8]) -> B;
3613 A platform-specific intrinsic function has the wrong number of type
3614 parameters. Erroneous code example:
3617 #![feature(repr_simd)]
3618 #![feature(platform_intrinsics)]
3621 struct f64x2(f64, f64);
3623 extern "platform-intrinsic" {
3624 fn x86_mm_movemask_pd<T>(x: f64x2) -> i32;
3625 // error: platform-specific intrinsic has wrong number of type
3630 Please refer to the function declaration to see if it corresponds
3631 with yours. Example:
3634 #![feature(repr_simd)]
3635 #![feature(platform_intrinsics)]
3638 struct f64x2(f64, f64);
3640 extern "platform-intrinsic" {
3641 fn x86_mm_movemask_pd(x: f64x2) -> i32;
3647 An unknown platform-specific intrinsic function was used. Erroneous
3651 #![feature(repr_simd)]
3652 #![feature(platform_intrinsics)]
3655 struct i16x8(i16, i16, i16, i16, i16, i16, i16, i16);
3657 extern "platform-intrinsic" {
3658 fn x86_mm_adds_ep16(x: i16x8, y: i16x8) -> i16x8;
3659 // error: unrecognized platform-specific intrinsic function
3663 Please verify that the function name wasn't misspelled, and ensure
3664 that it is declared in the rust source code (in the file
3665 src/librustc_platform_intrinsics/x86.rs). Example:
3668 #![feature(repr_simd)]
3669 #![feature(platform_intrinsics)]
3672 struct i16x8(i16, i16, i16, i16, i16, i16, i16, i16);
3674 extern "platform-intrinsic" {
3675 fn x86_mm_adds_epi16(x: i16x8, y: i16x8) -> i16x8; // ok!
3681 Intrinsic argument(s) and/or return value have the wrong type.
3682 Erroneous code example:
3685 #![feature(repr_simd)]
3686 #![feature(platform_intrinsics)]
3689 struct i8x16(i8, i8, i8, i8, i8, i8, i8, i8,
3690 i8, i8, i8, i8, i8, i8, i8, i8);
3692 struct i32x4(i32, i32, i32, i32);
3694 struct i64x2(i64, i64);
3696 extern "platform-intrinsic" {
3697 fn x86_mm_adds_epi16(x: i8x16, y: i32x4) -> i64x2;
3698 // error: intrinsic arguments/return value have wrong type
3702 To fix this error, please refer to the function declaration to give
3703 it the awaited types. Example:
3706 #![feature(repr_simd)]
3707 #![feature(platform_intrinsics)]
3710 struct i16x8(i16, i16, i16, i16, i16, i16, i16, i16);
3712 extern "platform-intrinsic" {
3713 fn x86_mm_adds_epi16(x: i16x8, y: i16x8) -> i16x8; // ok!
3719 Intrinsic argument(s) and/or return value have the wrong type.
3720 Erroneous code example:
3723 #![feature(repr_simd)]
3724 #![feature(platform_intrinsics)]
3727 struct i16x8(i16, i16, i16, i16, i16, i16, i16, i16);
3729 struct i64x8(i64, i64, i64, i64, i64, i64, i64, i64);
3731 extern "platform-intrinsic" {
3732 fn x86_mm_adds_epi16(x: i16x8, y: i16x8) -> i64x8;
3733 // error: intrinsic argument/return value has wrong type
3737 To fix this error, please refer to the function declaration to give
3738 it the awaited types. Example:
3741 #![feature(repr_simd)]
3742 #![feature(platform_intrinsics)]
3745 struct i16x8(i16, i16, i16, i16, i16, i16, i16, i16);
3747 extern "platform-intrinsic" {
3748 fn x86_mm_adds_epi16(x: i16x8, y: i16x8) -> i16x8; // ok!
3754 A platform-specific intrinsic function has wrong number of arguments.
3755 Erroneous code example:
3758 #![feature(repr_simd)]
3759 #![feature(platform_intrinsics)]
3762 struct f64x2(f64, f64);
3764 extern "platform-intrinsic" {
3765 fn x86_mm_movemask_pd(x: f64x2, y: f64x2, z: f64x2) -> i32;
3766 // error: platform-specific intrinsic has invalid number of arguments
3770 Please refer to the function declaration to see if it corresponds
3771 with yours. Example:
3774 #![feature(repr_simd)]
3775 #![feature(platform_intrinsics)]
3778 struct f64x2(f64, f64);
3780 extern "platform-intrinsic" {
3781 fn x86_mm_movemask_pd(x: f64x2) -> i32; // ok!
3787 The `typeof` keyword is currently reserved but unimplemented.
3788 Erroneous code example:
3792 let x: typeof(92) = 92;
3796 Try using type inference instead. Example:
3806 A non-default implementation was already made on this type so it cannot be
3807 specialized further. Erroneous code example:
3810 #![feature(specialization)]
3817 impl<T> SpaceLlama for T {
3818 default fn fly(&self) {}
3822 // applies to all `Clone` T and overrides the previous impl
3823 impl<T: Clone> SpaceLlama for T {
3827 // since `i32` is clone, this conflicts with the previous implementation
3828 impl SpaceLlama for i32 {
3829 default fn fly(&self) {}
3830 // error: item `fly` is provided by an `impl` that specializes
3831 // another, but the item in the parent `impl` is not marked
3832 // `default` and so it cannot be specialized.
3836 Specialization only allows you to override `default` functions in
3839 To fix this error, you need to mark all the parent implementations as default.
3843 #![feature(specialization)]
3850 impl<T> SpaceLlama for T {
3851 default fn fly(&self) {} // This is a parent implementation.
3854 // applies to all `Clone` T; overrides the previous impl
3855 impl<T: Clone> SpaceLlama for T {
3856 default fn fly(&self) {} // This is a parent implementation but was
3857 // previously not a default one, causing the error
3860 // applies to i32, overrides the previous two impls
3861 impl SpaceLlama for i32 {
3862 fn fly(&self) {} // And now that's ok!
3868 The number of elements in an array or slice pattern differed from the number of
3869 elements in the array being matched.
3871 Example of erroneous code:
3873 ```compile_fail,E0527
3874 #![feature(slice_patterns)]
3876 let r = &[1, 2, 3, 4];
3878 &[a, b] => { // error: pattern requires 2 elements but array
3880 println!("a={}, b={}", a, b);
3885 Ensure that the pattern is consistent with the size of the matched
3886 array. Additional elements can be matched with `..`:
3889 #![feature(slice_patterns)]
3891 let r = &[1, 2, 3, 4];
3893 &[a, b, ..] => { // ok!
3894 println!("a={}, b={}", a, b);
3901 An array or slice pattern required more elements than were present in the
3904 Example of erroneous code:
3906 ```compile_fail,E0528
3907 #![feature(slice_patterns)]
3911 &[a, b, c, rest..] => { // error: pattern requires at least 3
3912 // elements but array has 2
3913 println!("a={}, b={}, c={} rest={:?}", a, b, c, rest);
3918 Ensure that the matched array has at least as many elements as the pattern
3919 requires. You can match an arbitrary number of remaining elements with `..`:
3922 #![feature(slice_patterns)]
3924 let r = &[1, 2, 3, 4, 5];
3926 &[a, b, c, rest..] => { // ok!
3927 // prints `a=1, b=2, c=3 rest=[4, 5]`
3928 println!("a={}, b={}, c={} rest={:?}", a, b, c, rest);
3935 An array or slice pattern was matched against some other type.
3937 Example of erroneous code:
3939 ```compile_fail,E0529
3940 #![feature(slice_patterns)]
3944 [a, b] => { // error: expected an array or slice, found `f32`
3945 println!("a={}, b={}", a, b);
3950 Ensure that the pattern and the expression being matched on are of consistent
3954 #![feature(slice_patterns)]
3959 println!("a={}, b={}", a, b);
3966 An unknown field was specified into an enum's structure variant.
3968 Erroneous code example:
3970 ```compile_fail,E0559
3975 let s = Field::Fool { joke: 0 };
3976 // error: struct variant `Field::Fool` has no field named `joke`
3979 Verify you didn't misspell the field's name or that the field exists. Example:
3986 let s = Field::Fool { joke: 0 }; // ok!
3991 An unknown field was specified into a structure.
3993 Erroneous code example:
3995 ```compile_fail,E0560
4000 let s = Simba { mother: 1, father: 0 };
4001 // error: structure `Simba` has no field named `father`
4004 Verify you didn't misspell the field's name or that the field exists. Example:
4012 let s = Simba { mother: 1, father: 0 }; // ok!
4018 register_diagnostics! {
4023 E0103, // @GuillaumeGomez: I was unable to get this error, try your best!
4029 // E0159, // use of trait `{}` as struct constructor
4030 // E0163, // merged into E0071
4033 // E0173, // manual implementations of unboxed closure traits are experimental
4037 // E0187, // can't infer the kind of the closure
4038 // E0188, // can not cast an immutable reference to a mutable pointer
4039 // E0189, // deprecated: can only cast a boxed pointer to a boxed object
4040 // E0190, // deprecated: can only cast a &-pointer to an &-object
4041 E0196, // cannot determine a type for this closure
4042 E0203, // type parameter has more than one relaxed default bound,
4043 // and only one is supported
4045 // E0209, // builtin traits can only be implemented on structs or enums
4046 E0212, // cannot extract an associated type from a higher-ranked trait bound
4047 // E0213, // associated types are not accepted in this context
4048 // E0215, // angle-bracket notation is not stable with `Fn`
4049 // E0216, // parenthetical notation is only stable with `Fn`
4050 // E0217, // ambiguous associated type, defined in multiple supertraits
4051 // E0218, // no associated type defined
4052 // E0219, // associated type defined in higher-ranked supertrait
4053 // E0222, // Error code E0045 (variadic function must have C calling
4054 // convention) duplicate
4055 E0224, // at least one non-builtin train is required for an object type
4056 E0226, // only a single explicit lifetime bound is permitted
4057 E0227, // ambiguous lifetime bound, explicit lifetime bound required
4058 E0228, // explicit lifetime bound required
4059 E0230, // there is no type parameter on trait
4060 E0231, // only named substitution parameters are allowed
4063 // E0235, // structure constructor specifies a structure of type but
4064 // E0236, // no lang item for range syntax
4065 // E0237, // no lang item for range syntax
4066 E0238, // parenthesized parameters may only be used with a trait
4067 // E0239, // `next` method of `Iterator` trait has unexpected type
4071 E0245, // not a trait
4072 // E0246, // invalid recursive type
4075 // E0319, // trait impls for defaulted traits allowed just for structs/enums
4076 E0320, // recursive overflow during dropck
4077 E0328, // cannot implement Unsize explicitly
4078 // E0372, // coherence not object safe
4079 E0377, // the trait `CoerceUnsized` may only be implemented for a coercion
4080 // between structures with the same definition
4081 E0399, // trait items need to be implemented because the associated
4082 // type `{}` was overridden
4083 E0436, // functional record update requires a struct
4084 E0513, // no type for local variable ..
4085 E0521, // redundant default implementations of trait
4086 E0533, // `{}` does not name a unit variant, unit struct or a constant