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.
27 Here the `Apple` variant has two fields, and should be matched against like so:
36 Matching with the wrong number of fields has no sensible interpretation:
46 Check how many fields the enum was declared with and ensure that your pattern
51 This error indicates that a pattern attempted to extract the fields of an enum
52 variant with no fields. Here's a tiny example of this error:
55 // This enum has two variants.
57 // This variant has no fields.
59 // This variant has one field.
63 // Assuming x is a Number we can pattern match on its contents.
70 The pattern match `Zero(inside)` is incorrect because the `Zero` variant
71 contains no fields, yet the `inside` name attempts to bind the first field of
76 Each field of a struct can only be bound once in a pattern. Each occurrence of a
77 field name binds the value of that field, so to fix this error you will have to
78 remove or alter the duplicate uses of the field name. Perhaps you misspelt
83 This error indicates that a struct pattern attempted to extract a non-existant
84 field from a struct. Struct fields are identified by the name used before the
85 colon `:` so struct patterns should resemble the declaration of the struct type
95 let thing = Thing { x: 1, y: 2 };
97 Thing { x: xfield, y: yfield } => ...
101 If you are using shorthand field patterns but want to refer to the struct field
102 by a different name, you should rename it explicitly.
107 Thing { x, z } => ...
112 Thing { x, y: z } => ...
118 This error indicates that a pattern for a struct fails to specify a sub-pattern
119 for every one of the struct's fields. Ensure that each field from the struct's
120 definition is mentioned in the pattern, or use `..` to ignore unwanted fields.
130 let d = Dog { name: "Rusty".to_string(), age: 8 };
132 // This is incorrect.
134 Dog { age: x } => ...
137 // This is correct (explicit).
139 Dog { name: n, age: x } => ...
142 // This is also correct (ignore unused fields).
144 Dog { age: x, .. } => ...
150 In a match expression, only numbers and characters can be matched against a
151 range. This is because the compiler checks that the range is non-empty at
152 compile-time, and is unable to evaluate arbitrary comparison functions. If you
153 want to capture values of an orderable type between two end-points, you can use
157 // The ordering relation for strings can't be evaluated at compile time,
158 // so this doesn't work:
160 "hello" ... "world" => ...
164 // This is a more general version, using a guard:
166 s if s >= "hello" && s <= "world" => ...
173 This error indicates that a pointer to a trait type cannot be implicitly
174 dereferenced by a pattern. Every trait defines a type, but because the
175 size of trait implementors isn't fixed, this type has no compile-time size.
176 Therefore, all accesses to trait types must be through pointers. If you
177 encounter this error you should try to avoid dereferencing the pointer.
180 let trait_obj: &SomeTrait = ...;
182 // This tries to implicitly dereference to create an unsized local variable.
183 let &invalid = trait_obj;
185 // You can call methods without binding to the value being pointed at.
186 trait_obj.method_one();
187 trait_obj.method_two();
190 You can read more about trait objects in the Trait Object section of the
193 http://doc.rust-lang.org/reference.html#trait-objects
197 The compiler doesn't know what method to call because more than one method
198 has the same prototype. Example:
211 impl Trait1 for Test { fn foo() {} }
212 impl Trait2 for Test { fn foo() {} }
215 Test::foo() // error, which foo() to call?
219 To avoid this error, you have to keep only one of them and remove the others.
220 So let's take our example and fix it:
229 impl Trait1 for Test { fn foo() {} }
232 Test::foo() // and now that's good!
236 However, a better solution would be using fully explicit naming of type and
250 impl Trait1 for Test { fn foo() {} }
251 impl Trait2 for Test { fn foo() {} }
254 <Test as Trait1>::foo()
260 You tried to give a type parameter where it wasn't needed. Bad example:
272 x.method::<i32>(); // Error: Test::method doesn't need type parameter!
276 To fix this error, just remove the type parameter:
288 x.method(); // OK, we're good!
294 This error occurrs when you pass too many or not enough type parameters to
301 fn method<T>(&self, v: &[T]) -> usize {
310 x.method::<i32, i32>(v); // error: only one type parameter is expected!
314 To fix it, just specify a correct number of type parameters:
320 fn method<T>(&self, v: &[T]) -> usize {
329 x.method::<i32>(v); // OK, we're good!
333 Please note on the last example that we could have called `method` like this:
341 It is not allowed to manually call destructors in Rust. It is also not
342 necessary to do this since `drop` is called automatically whenever a value goes
345 Here's an example of this error:
359 let mut x = Foo { x: -7 };
360 x.drop(); // error: explicit use of destructor method
366 You can't use type parameters on foreign items. Example of erroneous code:
369 extern { fn some_func<T>(x: T); }
372 To fix this, replace the type parameter with the specializations that you
376 extern { fn some_func_i32(x: i32); }
377 extern { fn some_func_i64(x: i64); }
382 Rust only supports variadic parameters for interoperability with C code in its
383 FFI. As such, variadic parameters can only be used with functions which are
384 using the C ABI. Examples of erroneous code:
387 extern "rust-call" { fn foo(x: u8, ...); }
389 fn foo(x: u8, ...) {}
392 To fix such code, put them in an extern "C" block:
395 extern "C" fn foo (x: u8, ...);
404 When trying to make some type implement a trait `Foo`, you must, at minimum,
405 provide implementations for all of `Foo`'s required methods (meaning the
406 methods that do not have default implementations), as well as any required
407 trait items like associated types or constants.
411 This error indicates that an attempted implementation of a trait method
412 has the wrong number of type parameters.
414 For example, the trait below has a method `foo` with a type parameter `T`,
415 but the implementation of `foo` for the type `Bar` is missing this parameter:
419 fn foo<T: Default>(x: T) -> Self;
424 // error: method `foo` has 0 type parameters but its trait declaration has 1
427 fn foo(x: bool) -> Self { Bar }
433 This error indicates that an attempted implementation of a trait method
434 has the wrong number of function parameters.
436 For example, the trait below has a method `foo` with two function parameters
437 (`&self` and `u8`), but the implementation of `foo` for the type `Bar` omits
442 fn foo(&self, x: u8) -> bool;
447 // error: method `foo` has 1 parameter but the declaration in trait `Foo::foo`
450 fn foo(&self) -> bool { true }
456 The parameters of any trait method must match between a trait implementation
457 and the trait definition.
459 Here are a couple examples of this error:
470 // error, expected u16, found i16
473 // error, values differ in mutability
474 fn bar(&mut self) { }
480 It is not allowed to cast to a bool. If you are trying to cast a numeric type
481 to a bool, you can compare it with zero instead:
487 let x_is_nonzero = x != 0;
489 // Not allowed, won't compile
490 let x_is_nonzero = x as bool;
495 During a method call, a value is automatically dereferenced as many times as
496 needed to make the value's type match the method's receiver. The catch is that
497 the compiler will only attempt to dereference a number of times up to the
498 recursion limit (which can be set via the `recursion_limit` attribute).
500 For a somewhat artificial example:
503 #![recursion_limit="2"]
515 // error, reached the recursion limit while auto-dereferencing &&Foo
520 One fix may be to increase the recursion limit. Note that it is possible to
521 create an infinite recursion of dereferencing, in which case the only fix is to
522 somehow break the recursion.
526 When invoking closures or other implementations of the function traits `Fn`,
527 `FnMut` or `FnOnce` using call notation, the number of parameters passed to the
528 function must match its definition.
530 An example using a closure:
534 let a = f(); // invalid, too few parameters
535 let b = f(4); // this works!
536 let c = f(2, 3); // invalid, too many parameters
539 A generic function must be treated similarly:
542 fn foo<F: Fn()>(f: F) {
543 f(); // this is valid, but f(3) would not work
549 The built-in function traits are generic over a tuple of the function arguments.
550 If one uses angle-bracket notation (`Fn<(T,), Output=U>`) instead of parentheses
551 (`Fn(T) -> U`) to denote the function trait, the type parameter should be a
552 tuple. Otherwise function call notation cannot be used and the trait will not be
553 implemented by closures.
555 The most likely source of this error is using angle-bracket notation without
556 wrapping the function argument type into a tuple, for example:
559 fn foo<F: Fn<i32>>(f: F) -> F::Output { f(3) }
562 It can be fixed by adjusting the trait bound like this:
565 fn foo<F: Fn<(i32,)>>(f: F) -> F::Output { f(3) }
568 Note that `(T,)` always denotes the type of a 1-tuple containing an element of
569 type `T`. The comma is necessary for syntactic disambiguation.
573 External C functions are allowed to be variadic. However, a variadic function
574 takes a minimum number of arguments. For example, consider C's variadic `printf`
579 use libc::{ c_char, c_int };
582 fn printf(_: *const c_char, ...) -> c_int;
586 Using this declaration, it must be called with at least one argument, so
587 simply calling `printf()` is invalid. But the following uses are allowed:
591 use std::ffi::CString;
593 printf(CString::new("test\n").unwrap().as_ptr());
594 printf(CString::new("number = %d\n").unwrap().as_ptr(), 3);
595 printf(CString::new("%d, %d\n").unwrap().as_ptr(), 10, 5);
601 The number of arguments passed to a function must match the number of arguments
602 specified in the function signature.
604 For example, a function like
607 fn f(a: u16, b: &str) {}
610 must always be called with exactly two arguments, e.g. `f(2, "test")`.
612 Note, that Rust does not have a notion of optional function arguments or
613 variadic functions (except for its C-FFI).
617 This error indicates that during an attempt to build a struct or struct-like
618 enum variant, one of the fields was specified more than once. Each field should
619 be specified exactly one time.
623 This error indicates that during an attempt to build a struct or struct-like
624 enum variant, one of the fields was not provided. Each field should be
625 specified exactly once.
629 Box placement expressions (like C++'s "placement new") do not yet support any
630 place expression except the exchange heap (i.e. `std::boxed::HEAP`).
631 Furthermore, the syntax is changing to use `in` instead of `box`. See [RFC 470]
632 and [RFC 809] for more details.
634 [RFC 470]: https://github.com/rust-lang/rfcs/pull/470
635 [RFC 809]: https://github.com/rust-lang/rfcs/pull/809
639 The left-hand side of a compound assignment expression must be an lvalue
640 expression. An lvalue expression represents a memory location and includes
641 item paths (ie, namespaced variables), dereferences, indexing expressions,
642 and field references.
644 Let's start with some bad examples:
646 use std::collections::LinkedList;
648 // Bad: assignment to non-lvalue expression
649 LinkedList::new() += 1;
653 fn some_func(i: &mut i32) {
654 i += 12; // Error : '+=' operation cannot be applied on a reference !
657 And now some good examples:
665 fn some_func(i: &mut i32) {
673 The compiler found a function whose body contains a `return;` statement but
674 whose return type is not `()`. An example of this is:
683 Since `return;` is just like `return ();`, there is a mismatch between the
684 function's return type and the value being returned.
688 The left-hand side of an assignment operator must be an lvalue expression. An
689 lvalue expression represents a memory location and can be a variable (with
690 optional namespacing), a dereference, an indexing expression or a field
693 More details can be found here:
694 https://doc.rust-lang.org/reference.html#lvalues,-rvalues-and-temporaries
696 Now, we can go further. Here are some bad examples:
702 const SOME_CONST : i32 = 12;
704 fn some_other_func() {}
707 SOME_CONST = 14; // error : a constant value cannot be changed!
708 1 = 3; // error : 1 isn't a valid lvalue!
709 some_other_func() = 4; // error : we can't assign value to a function!
710 SomeStruct.x = 12; // error : SomeStruct a structure name but it is used
715 And now let's give good examples:
722 let mut s = SomeStruct {x: 0, y: 0};
724 s.x = 3; // that's good !
728 fn some_func(x: &mut i32) {
729 *x = 12; // that's good !
735 You tried to use a structure initialization with a non-structure type.
736 Example of erroneous code:
739 enum Foo { FirstValue };
741 let u = Foo::FirstValue { value: 0i32 }; // error: Foo::FirstValue
742 // isn't a structure!
743 // or even simpler, if the structure wasn't defined at all:
744 let u = RandomName { random_field: 0i32 }; // error: RandomName
745 // isn't a structure!
748 To fix this, please check:
749 * Did you spell it right?
750 * Did you accidentaly used an enum as a struct?
751 * Did you accidentaly make an enum when you intended to use a struct?
753 Here is the previous code with all missing information:
765 let u = Foo::FirstValue(Inner { value: 0i32 });
767 let t = Inner { value: 0i32 };
773 When defining a recursive struct or enum, any use of the type being defined
774 from inside the definition must occur behind a pointer (like `Box` or `&`).
775 This is because structs and enums must have a well-defined size, and without
776 the pointer the size of the type would need to be unbounded.
778 Consider the following erroneous definition of a type for a list of bytes:
781 // error, invalid recursive struct type
784 tail: Option<ListNode>,
788 This type cannot have a well-defined size, because it needs to be arbitrarily
789 large (since we would be able to nest `ListNode`s to any depth). Specifically,
792 size of `ListNode` = 1 byte for `head`
793 + 1 byte for the discriminant of the `Option`
797 One way to fix this is by wrapping `ListNode` in a `Box`, like so:
802 tail: Option<Box<ListNode>>,
806 This works because `Box` is a pointer, so its size is well-known.
810 You cannot define a struct (or enum) `Foo` that requires an instance of `Foo`
811 in order to make a new `Foo` value. This is because there would be no way a
812 first instance of `Foo` could be made to initialize another instance!
814 Here's an example of a struct that has this problem:
817 struct Foo { x: Box<Foo> } // error
820 One fix is to use `Option`, like so:
823 struct Foo { x: Option<Box<Foo>> }
826 Now it's possible to create at least one instance of `Foo`: `Foo { x: None }`.
830 When using the `#[simd]` attribute on a tuple struct, the components of the
831 tuple struct must all be of a concrete, nongeneric type so the compiler can
832 reason about how to use SIMD with them. This error will occur if the types
837 struct Bad<T>(T, T, T); // This will cause an error
840 struct Good(u32, u32, u32); // This will not
845 The `#[simd]` attribute can only be applied to non empty tuple structs, because
846 it doesn't make sense to try to use SIMD operations when there are no values to
851 struct Bad; // This will cause an error
854 struct Good(u32); // This will not
859 When using the `#[simd]` attribute to automatically use SIMD operations in tuple
860 struct, the types in the struct must all be of the same type, or the compiler
861 will trigger this error.
865 struct Bad(u16, u32, u32); // This will cause an error
868 struct Good(u32, u32, u32); // This will not
874 When using the `#[simd]` attribute on a tuple struct, the elements in the tuple
875 must be machine types so SIMD operations can be applied to them.
879 struct Bad(String); // This will cause an error
882 struct Good(u32, u32, u32); // This will not
887 Enum variants which contain no data can be given a custom integer
888 representation. This error indicates that the value provided is not an integer
889 literal and is therefore invalid.
891 For example, in the following code,
899 we try to set the representation to a string.
901 There's no general fix for this; if you can work with an integer then just set
910 however if you actually wanted a mapping between variants and non-integer
911 objects, it may be preferable to use a method with a match instead:
916 fn get_str(&self) -> &'static str {
926 This error indicates that the compiler was unable to sensibly evaluate an
927 integer expression provided as an enum discriminant. Attempting to divide by 0
928 or causing integer overflow are two ways to induce this error. For example:
937 Ensure that the expressions given can be evaluated as the desired integer type.
938 See the FFI section of the Reference for more information about using a custom
941 https://doc.rust-lang.org/reference.html#ffi-attributes
945 Enum discriminants are used to differentiate enum variants stored in memory.
946 This error indicates that the same value was used for two or more variants,
947 making them impossible to tell apart.
965 Note that variants without a manually specified discriminant are numbered from
966 top to bottom starting from 0, so clashes can occur with seemingly unrelated
976 Here `X` will have already been assigned the discriminant 0 by the time `Y` is
977 encountered, so a conflict occurs.
981 The default type for enum discriminants is `isize`, but it can be adjusted by
982 adding the `repr` attribute to the enum declaration. This error indicates that
983 an integer literal given as a discriminant is not a member of the discriminant
994 Here, 1024 lies outside the valid range for `u8`, so the discriminant for `A` is
995 invalid. You may want to change representation types to fix this, or else change
996 invalid discriminant values so that they fit within the existing type.
998 Note also that without a representation manually defined, the compiler will
999 optimize by using the smallest integer type possible.
1003 At present, it's not possible to define a custom representation for an enum with
1004 a single variant. As a workaround you can add a `Dummy` variant.
1006 See: https://github.com/rust-lang/rust/issues/10292
1010 It is impossible to define an integer type to be used to represent zero-variant
1011 enum values because there are no zero-variant enum values. There is no way to
1012 construct an instance of the following type using only safe code:
1020 Too many type parameters were supplied for a function. For example:
1026 foo::<f64, bool>(); // error, expected 1 parameter, found 2 parameters
1030 The number of supplied parameters much exactly match the number of defined type
1035 You gave too many lifetime parameters. Erroneous code example:
1041 f::<'static>() // error: too many lifetime parameters provided
1045 Please check you give the right number of lifetime parameters. Example:
1055 It's also important to note that the Rust compiler can generally
1056 determine the lifetime by itself. Example:
1064 // it can be written like this
1065 fn get_value<'a>(&'a self) -> &'a str { &self.value }
1066 // but the compiler works fine with this too:
1067 fn without_lifetime(&self) -> &str { &self.value }
1071 let f = Foo { value: "hello".to_owned() };
1073 println!("{}", f.get_value());
1074 println!("{}", f.without_lifetime());
1080 Not enough type parameters were supplied for a function. For example:
1086 foo::<f64>(); // error, expected 2 parameters, found 1 parameter
1090 Note that if a function takes multiple type parameters but you want the compiler
1091 to infer some of them, you can use type placeholders:
1094 fn foo<T, U>(x: T) {}
1098 foo::<f64>(x); // error, expected 2 parameters, found 1 parameter
1099 foo::<_, f64>(x); // same as `foo::<bool, f64>(x)`
1105 You gave an unnecessary type parameter in a type alias. Erroneous code
1109 type Foo<T> = u32; // error: type parameter `T` is unused
1111 type Foo<A,B> = Box<A>; // error: type parameter `B` is unused
1114 Please check you didn't write too many type parameters. Example:
1117 type Foo = u32; // ok!
1118 type Foo<A> = Box<A>; // ok!
1123 You tried to declare an undefined atomic operation function.
1124 Erroneous code example:
1127 #![feature(intrinsics)]
1129 extern "rust-intrinsic" {
1130 fn atomic_foo(); // error: unrecognized atomic operation
1135 Please check you didn't make a mistake in the function's name. All intrinsic
1136 functions are defined in librustc_trans/trans/intrinsic.rs and in
1137 libcore/intrinsics.rs in the Rust source code. Example:
1140 #![feature(intrinsics)]
1142 extern "rust-intrinsic" {
1143 fn atomic_fence(); // ok!
1149 You declared an unknown intrinsic function. Erroneous code example:
1152 #![feature(intrinsics)]
1154 extern "rust-intrinsic" {
1155 fn foo(); // error: unrecognized intrinsic function: `foo`
1165 Please check you didn't make a mistake in the function's name. All intrinsic
1166 functions are defined in librustc_trans/trans/intrinsic.rs and in
1167 libcore/intrinsics.rs in the Rust source code. Example:
1170 #![feature(intrinsics)]
1172 extern "rust-intrinsic" {
1173 fn atomic_fence(); // ok!
1185 You gave an invalid number of type parameters to an intrinsic function.
1186 Erroneous code example:
1189 #![feature(intrinsics)]
1191 extern "rust-intrinsic" {
1192 fn size_of<T, U>() -> usize; // error: intrinsic has wrong number
1193 // of type parameters
1197 Please check that you provided the right number of lifetime parameters
1198 and verify with the function declaration in the Rust source code.
1202 #![feature(intrinsics)]
1204 extern "rust-intrinsic" {
1205 fn size_of<T>() -> usize; // ok!
1211 You hit this error because the compiler the compiler lacks information
1212 to determine a type for this expression. Erroneous code example:
1216 let x = |_| {}; // error: cannot determine a type for this expression
1220 You have two possibilities to solve this situation:
1221 * Give an explicit definition of the expression
1222 * Infer the expression
1228 let x = |_ : u32| {}; // ok!
1237 You hit this error because the compiler lacks information to
1238 determine a type for this variable. Erroneous code example:
1241 fn demo(devil: fn () -> !) {
1242 let x: &_ = devil();
1243 // error: cannot determine a type for this local variable
1246 fn oh_no() -> ! { panic!("the devil is in the details") }
1253 To solve this situation, constrain the type of the variable.
1257 fn some_func(x: &u32) {
1261 fn demo(devil: fn () -> !) {
1262 let x: &u32 = devil();
1263 // Here we defined the type at the variable creation
1265 let x: &_ = devil();
1267 // Here, the type is determined by the function argument type
1270 fn oh_no() -> ! { panic!("the devil is in the details") }
1279 This error indicates that a lifetime is missing from a type. If it is an error
1280 inside a function signature, the problem may be with failing to adhere to the
1281 lifetime elision rules (see below).
1283 Here are some simple examples of where you'll run into this error:
1286 struct Foo { x: &bool } // error
1287 struct Foo<'a> { x: &'a bool } // correct
1289 enum Bar { A(u8), B(&bool), } // error
1290 enum Bar<'a> { A(u8), B(&'a bool), } // correct
1292 type MyStr = &str; // error
1293 type MyStr<'a> = &'a str; //correct
1297 Lifetime elision is a special, limited kind of inference for lifetimes in
1298 function signatures which allows you to leave out lifetimes in certain cases.
1299 For more background on lifetime elision see [the book][book-le].
1301 The lifetime elision rules require that any function signature with an elided
1302 output lifetime must either have
1304 - exactly one input lifetime
1305 - or, multiple input lifetimes, but the function must also be a method with a
1306 `&self` or `&mut self` receiver
1308 In the first case, the output lifetime is inferred to be the same as the unique
1309 input lifetime. In the second case, the lifetime is instead inferred to be the
1310 same as the lifetime on `&self` or `&mut self`.
1312 Here are some examples of elision errors:
1315 // error, no input lifetimes
1316 fn foo() -> &str { ... }
1318 // error, `x` and `y` have distinct lifetimes inferred
1319 fn bar(x: &str, y: &str) -> &str { ... }
1321 // error, `y`'s lifetime is inferred to be distinct from `x`'s
1322 fn baz<'a>(x: &'a str, y: &str) -> &str { ... }
1325 [book-le]: http://doc.rust-lang.org/nightly/book/lifetimes.html#lifetime-elision
1329 This error means that an incorrect number of lifetime parameters were provided
1330 for a type (like a struct or enum) or trait.
1332 Some basic examples include:
1335 struct Foo<'a>(&'a str);
1336 enum Bar { A, B, C }
1339 foo: Foo, // error: expected 1, found 0
1340 bar: Bar<'a>, // error: expected 0, found 1
1344 Here's an example that is currently an error, but may work in a future version
1348 struct Foo<'a>(&'a str);
1351 impl Quux for Foo { } // error: expected 1, found 0
1354 Lifetime elision in implementation headers was part of the lifetime elision
1355 RFC. It is, however, [currently unimplemented][iss15872].
1357 [iss15872]: https://github.com/rust-lang/rust/issues/15872
1361 You can only define an inherent implementation for a type in the same crate
1362 where the type was defined. For example, an `impl` block as below is not allowed
1363 since `Vec` is defined in the standard library:
1366 impl Vec<u8> { ... } // error
1369 To fix this problem, you can do either of these things:
1371 - define a trait that has the desired associated functions/types/constants and
1372 implement the trait for the type in question
1373 - define a new type wrapping the type and define an implementation on the new
1376 Note that using the `type` keyword does not work here because `type` only
1377 introduces a type alias:
1380 type Bytes = Vec<u8>;
1382 impl Bytes { ... } // error, same as above
1387 This error indicates a violation of one of Rust's orphan rules for trait
1388 implementations. The rule prohibits any implementation of a foreign trait (a
1389 trait defined in another crate) where
1391 - the type that is implementing the trait is foreign
1392 - all of the parameters being passed to the trait (if there are any) are also
1395 Here's one example of this error:
1398 impl Drop for u32 {}
1401 To avoid this kind of error, ensure that at least one local type is referenced
1405 pub struct Foo; // you define your type in your crate
1407 impl Drop for Foo { // and you can implement the trait on it!
1408 // code of trait implementation here
1411 impl From<Foo> for i32 { // or you use a type from your crate as
1413 fn from(i: Foo) -> i32 {
1419 Alternatively, define a trait locally and implement that instead:
1423 fn get(&self) -> usize;
1427 fn get(&self) -> usize { 0 }
1431 For information on the design of the orphan rules, see [RFC 1023].
1433 [RFC 1023]: https://github.com/rust-lang/rfcs/pull/1023
1437 There are conflicting trait implementations for the same type.
1438 Example of erroneous code:
1442 fn get(&self) -> usize;
1445 impl<T> MyTrait for T {
1446 fn get(&self) -> usize { 0 }
1453 impl MyTrait for Foo { // error: conflicting implementations for trait
1455 fn get(&self) -> usize { self.value }
1459 When looking for the implementation for the trait, the compiler finds
1460 both the `impl<T> MyTrait for T` where T is all types and the `impl
1461 MyTrait for Foo`. Since a trait cannot be implemented multiple times,
1462 this is an error. So, when you write:
1465 impl<T> MyTrait for T {
1466 fn get(&self) -> usize { 0 }
1470 This makes the trait implemented on all types in the scope. So if you
1471 try to implement it on another one after that, the implementations will
1476 fn get(&self) -> usize;
1479 impl<T> MyTrait for T {
1480 fn get(&self) -> usize { 0 }
1488 f.get(); // the trait is implemented so we can use it
1494 An attempt was made to implement Drop on a trait, which is not allowed: only
1495 structs and enums can implement Drop. An example causing this error:
1500 impl Drop for MyTrait {
1501 fn drop(&mut self) {}
1505 A workaround for this problem is to wrap the trait up in a struct, and implement
1506 Drop on that. An example is shown below:
1510 struct MyWrapper<T: MyTrait> { foo: T }
1512 impl <T: MyTrait> Drop for MyWrapper<T> {
1513 fn drop(&mut self) {}
1518 Alternatively, wrapping trait objects requires something like the following:
1523 //or Box<MyTrait>, if you wanted an owned trait object
1524 struct MyWrapper<'a> { foo: &'a MyTrait }
1526 impl <'a> Drop for MyWrapper<'a> {
1527 fn drop(&mut self) {}
1533 In order to be consistent with Rust's lack of global type inference, type
1534 placeholders are disallowed by design in item signatures.
1536 Examples of this error include:
1539 fn foo() -> _ { 5 } // error, explicitly write out the return type instead
1541 static BAR: _ = "test"; // error, explicitly write out the type instead
1546 You declared two fields of a struct with the same name. Erroneous code
1552 field1: i32 // error: field is already declared
1556 Please verify that the field names have been correctly spelled. Example:
1567 Type parameter defaults can only use parameters that occur before them.
1568 Erroneous code example:
1571 pub struct Foo<T=U, U=()> {
1575 // error: type parameters with a default cannot use forward declared
1579 Since type parameters are evaluated in-order, you may be able to fix this issue
1583 pub struct Foo<U=(), T=U> {
1589 Please also verify that this wasn't because of a name-clash and rename the type
1594 You declared a pattern as an argument in a foreign function declaration.
1595 Erroneous code example:
1599 fn foo((a, b): (u32, u32)); // error: patterns aren't allowed in foreign
1600 // function declarations
1604 Please replace the pattern argument with a regular one. Example:
1613 fn foo(s: SomeStruct); // ok!
1617 fn foo(a: (u32, u32)); // ok!
1623 It is not possible to define `main` with type parameters, or even with function
1624 parameters. When `main` is present, it must take no arguments and return `()`.
1628 It is not possible to declare type parameters on a function that has the `start`
1629 attribute. Such a function must have the following type signature:
1632 fn(isize, *const *const u8) -> isize
1637 You tried to use a trait as a struct constructor. Erroneous code example:
1640 trait TraitNotAStruct {}
1642 TraitNotAStruct{ value: 0 }; // error: use of trait `TraitNotAStruct` as a
1643 // struct constructor
1646 Please verify you used the correct type name or please implement the trait
1647 on a struct and use this struct constructor. Example:
1650 trait TraitNotAStruct {}
1656 Foo{ value: 0 }; // ok!
1661 This error means that the compiler found a return expression in a function
1662 marked as diverging. A function diverges if it has `!` in the place of the
1663 return type in its signature. For example:
1666 fn foo() -> ! { return; } // error
1669 For a function that diverges, every control path in the function must never
1670 return, for example with a `loop` that never breaks or a call to another
1671 diverging function (such as `panic!()`).
1675 This error means that an attempt was made to specify the type of a variable with
1676 a combination of a concrete type and a trait. Consider the following example:
1679 fn foo(bar: i32+std::fmt::Display) {}
1682 The code is trying to specify that we want to receive a signed 32-bit integer
1683 which also implements `Display`. This doesn't make sense: when we pass `i32`, a
1684 concrete type, it implicitly includes all of the traits that it implements.
1685 This includes `Display`, `Debug`, `Clone`, and a host of others.
1687 If `i32` implements the trait we desire, there's no need to specify the trait
1688 separately. If it does not, then we need to `impl` the trait for `i32` before
1689 passing it into `foo`. Either way, a fixed definition for `foo` will look like
1696 To learn more about traits, take a look at the Book:
1698 https://doc.rust-lang.org/book/traits.html
1702 In types, the `+` type operator has low precedence, so it is often necessary
1711 w: &'a Foo + Copy, // error, use &'a (Foo + Copy)
1712 x: &'a Foo + 'a, // error, use &'a (Foo + 'a)
1713 y: &'a mut Foo + 'a, // error, use &'a mut (Foo + 'a)
1714 z: fn() -> Foo + 'a, // error, use fn() -> (Foo + 'a)
1718 More details can be found in [RFC 438].
1720 [RFC 438]: https://github.com/rust-lang/rfcs/pull/438
1724 Explicitly implementing both Drop and Copy for a type is currently disallowed.
1725 This feature can make some sense in theory, but the current implementation is
1726 incorrect and can lead to memory unsafety (see [issue #20126][iss20126]), so
1727 it has been disabled for now.
1729 [iss20126]: https://github.com/rust-lang/rust/issues/20126
1733 An associated function for a trait was defined to be static, but an
1734 implementation of the trait declared the same function to be a method (i.e. to
1735 take a `self` parameter).
1737 Here's an example of this error:
1747 // error, method `foo` has a `&self` declaration in the impl, but not in
1754 An associated function for a trait was defined to be a method (i.e. to take a
1755 `self` parameter), but an implementation of the trait declared the same function
1758 Here's an example of this error:
1768 // error, method `foo` has a `&self` declaration in the trait, but not in
1776 Trait objects need to have all associated types specified. Erroneous code
1784 type Foo = Trait; // error: the value of the associated type `Bar` (from
1785 // the trait `Trait`) must be specified
1788 Please verify you specified all associated types of the trait and that you
1789 used the right trait. Example:
1796 type Foo = Trait<Bar=i32>; // ok!
1801 Negative impls are only allowed for traits with default impls. For more
1802 information see the [opt-in builtin traits RFC](https://github.com/rust-lang/
1803 rfcs/blob/master/text/0019-opt-in-builtin-traits.md).
1807 Your method's lifetime parameters do not match the trait declaration.
1808 Erroneous code example:
1812 fn bar<'a,'b:'a>(x: &'a str, y: &'b str);
1817 impl Trait for Foo {
1818 fn bar<'a,'b>(x: &'a str, y: &'b str) {
1819 // error: lifetime parameters or bounds on method `bar`
1820 // do not match the trait declaration
1825 The lifetime constraint `'b` for bar() implementation does not match the
1826 trait declaration. Ensure lifetime declarations match exactly in both trait
1827 declaration and implementation. Example:
1831 fn t<'a,'b:'a>(x: &'a str, y: &'b str);
1836 impl Trait for Foo {
1837 fn t<'a,'b:'a>(x: &'a str, y: &'b str) { // ok!
1844 Inherent implementations (one that do not implement a trait but provide
1845 methods associated with a type) are always safe because they are not
1846 implementing an unsafe trait. Removing the `unsafe` keyword from the inherent
1847 implementation will resolve this error.
1852 // this will cause this error
1854 // converting it to this will fix it
1861 A negative implementation is one that excludes a type from implementing a
1862 particular trait. Not being able to use a trait is always a safe operation,
1863 so negative implementations are always safe and never need to be marked as
1869 // unsafe is unnecessary
1870 unsafe impl !Clone for Foo { }
1871 // this will compile
1872 impl !Clone for Foo { }
1878 Safe traits should not have unsafe implementations, therefore marking an
1879 implementation for a safe trait unsafe will cause a compiler error. Removing the
1880 unsafe marker on the trait noted in the error will resolve this problem.
1887 // this won't compile because Bar is safe
1888 unsafe impl Bar for Foo { }
1889 // this will compile
1890 impl Bar for Foo { }
1896 Unsafe traits must have unsafe implementations. This error occurs when an
1897 implementation for an unsafe trait isn't marked as unsafe. This may be resolved
1898 by marking the unsafe implementation as unsafe.
1903 unsafe trait Bar { }
1905 // this won't compile because Bar is unsafe and impl isn't unsafe
1906 impl Bar for Foo { }
1907 // this will compile
1908 unsafe impl Bar for Foo { }
1914 It is an error to define two associated items (like methods, associated types,
1915 associated functions, etc.) with the same identifier.
1923 fn bar(&self) -> bool { self.0 > 5 }
1924 fn bar() {} // error: duplicate associated function
1929 fn baz(&self) -> bool;
1935 fn baz(&self) -> bool { true }
1937 // error: duplicate method
1938 fn baz(&self) -> bool { self.0 > 5 }
1940 // error: duplicate associated type
1947 Inherent associated types were part of [RFC 195] but are not yet implemented.
1948 See [the tracking issue][iss8995] for the status of this implementation.
1950 [RFC 195]: https://github.com/rust-lang/rfcs/pull/195
1951 [iss8995]: https://github.com/rust-lang/rust/issues/8995
1955 An attempt to implement the `Copy` trait for a struct failed because one of the
1956 fields does not implement `Copy`. To fix this, you must implement `Copy` for the
1957 mentioned field. Note that this may not be possible, as in the example of
1964 impl Copy for Foo { }
1967 This fails because `Vec<T>` does not implement `Copy` for any `T`.
1969 Here's another example that will fail:
1978 This fails because `&mut T` is not `Copy`, even when `T` is `Copy` (this
1979 differs from the behavior for `&T`, which is always `Copy`).
1983 An attempt to implement the `Copy` trait for an enum failed because one of the
1984 variants does not implement `Copy`. To fix this, you must implement `Copy` for
1985 the mentioned variant. Note that this may not be possible, as in the example of
1993 impl Copy for Foo { }
1996 This fails because `Vec<T>` does not implement `Copy` for any `T`.
1998 Here's another example that will fail:
2008 This fails because `&mut T` is not `Copy`, even when `T` is `Copy` (this
2009 differs from the behavior for `&T`, which is always `Copy`).
2013 You can only implement `Copy` for a struct or enum. Both of the following
2014 examples will fail, because neither `i32` (primitive type) nor `&'static Bar`
2015 (reference to `Bar`) is a struct or enum:
2019 impl Copy for Foo { } // error
2021 #[derive(Copy, Clone)]
2023 impl Copy for &'static Bar { } // error
2028 You declared an unused type parameter when implementing a trait on an object.
2029 Erroneous code example:
2033 fn get(&self) -> usize;
2038 impl<T> MyTrait for Foo {
2039 fn get(&self) -> usize {
2045 Please check your object definition and remove unused type
2046 parameter(s). Example:
2050 fn get(&self) -> usize;
2055 impl MyTrait for Foo {
2056 fn get(&self) -> usize {
2064 This error indicates a violation of one of Rust's orphan rules for trait
2065 implementations. The rule concerns the use of type parameters in an
2066 implementation of a foreign trait (a trait defined in another crate), and
2067 states that type parameters must be "covered" by a local type. To understand
2068 what this means, it is perhaps easiest to consider a few examples.
2070 If `ForeignTrait` is a trait defined in some external crate `foo`, then the
2071 following trait `impl` is an error:
2075 use foo::ForeignTrait;
2077 impl<T> ForeignTrait for T { ... } // error
2080 To work around this, it can be covered with a local type, `MyType`:
2083 struct MyType<T>(T);
2084 impl<T> ForeignTrait for MyType<T> { ... } // Ok
2087 For another example of an error, suppose there's another trait defined in `foo`
2088 named `ForeignTrait2` that takes two type parameters. Then this `impl` results
2089 in the same rule violation:
2093 impl<T> ForeignTrait2<T, MyType<T>> for MyType2 { ... } // error
2096 The reason for this is that there are two appearances of type parameter `T` in
2097 the `impl` header, both as parameters for `ForeignTrait2`. The first appearance
2098 is uncovered, and so runs afoul of the orphan rule.
2100 Consider one more example:
2103 impl<T> ForeignTrait2<MyType<T>, T> for MyType2 { ... } // Ok
2106 This only differs from the previous `impl` in that the parameters `T` and
2107 `MyType<T>` for `ForeignTrait2` have been swapped. This example does *not*
2108 violate the orphan rule; it is permitted.
2110 To see why that last example was allowed, you need to understand the general
2111 rule. Unfortunately this rule is a bit tricky to state. Consider an `impl`:
2114 impl<P1, ..., Pm> ForeignTrait<T1, ..., Tn> for T0 { ... }
2117 where `P1, ..., Pm` are the type parameters of the `impl` and `T0, ..., Tn`
2118 are types. One of the types `T0, ..., Tn` must be a local type (this is another
2119 orphan rule, see the explanation for E0117). Let `i` be the smallest integer
2120 such that `Ti` is a local type. Then no type parameter can appear in any of the
2123 For information on the design of the orphan rules, see [RFC 1023].
2125 [RFC 1023]: https://github.com/rust-lang/rfcs/pull/1023
2129 You used an intrinsic function which doesn't correspond to its
2130 definition. Erroneous code example:
2133 #![feature(intrinsics)]
2135 extern "rust-intrinsic" {
2136 fn size_of<T>(); // error: intrinsic has wrong type
2140 Please check the function definition. Example:
2143 #![feature(intrinsics)]
2145 extern "rust-intrinsic" {
2146 fn size_of<T>() -> usize;
2152 You used an associated type which isn't defined in the trait.
2153 Erroneous code example:
2160 type Foo = Trait<F=i32>; // error: associated type `F` not found for
2164 Please verify you used the right trait or you didn't misspell the
2165 associated type name. Example:
2172 type Foo = Trait<Bar=i32>; // ok!
2177 An attempt was made to retrieve an associated type, but the type was ambiguous.
2181 trait MyTrait {type X; }
2184 let foo: MyTrait::X;
2188 The problem here is that we're attempting to take the type of X from MyTrait.
2189 Unfortunately, the type of X is not defined, because it's only made concrete in
2190 implementations of the trait. A working version of this code might look like:
2193 trait MyTrait {type X; }
2196 impl MyTrait for MyStruct {
2201 let foo: <MyStruct as MyTrait>::X;
2205 This syntax specifies that we want the X type from MyTrait, as made concrete in
2206 MyStruct. The reason that we cannot simply use `MyStruct::X` is that MyStruct
2207 might implement two different traits with identically-named associated types.
2208 This syntax allows disambiguation between the two.
2212 You attempted to use multiple types as bounds for a closure or trait object.
2213 Rust does not currently support this. A simple example that causes this error:
2217 let _: Box<std::io::Read+std::io::Write>;
2221 Builtin traits are an exception to this rule: it's possible to have bounds of
2222 one non-builtin type, plus any number of builtin types. For example, the
2223 following compiles correctly:
2227 let _: Box<std::io::Read+Copy+Sync>;
2233 The attribute must have a value. Erroneous code example:
2236 #[rustc_on_unimplemented] // error: this attribute must have a value
2240 Please supply the missing value of the attribute. Example:
2243 #[rustc_on_unimplemented = "foo"] // ok!
2249 This error indicates that not enough type parameters were found in a type or
2252 For example, the `Foo` struct below is defined to be generic in `T`, but the
2253 type parameter is missing in the definition of `Bar`:
2256 struct Foo<T> { x: T }
2258 struct Bar { x: Foo }
2263 This error indicates that too many type parameters were found in a type or
2266 For example, the `Foo` struct below has no type parameters, but is supplied
2267 with two in the definition of `Bar`:
2270 struct Foo { x: bool }
2272 struct Bar<S, T> { x: Foo<S, T> }
2277 This error indicates a constant expression for the array length was found, but
2278 it was not an integer (signed or unsigned) expression.
2280 Some examples of code that produces this error are:
2283 const A: [u32; "hello"] = []; // error
2284 const B: [u32; true] = []; // error
2285 const C: [u32; 0.0] = []; // error
2289 There was an error while evaluating the expression for the length of a fixed-
2292 Some examples of this error are:
2295 // divide by zero in the length expression
2296 const A: [u32; 1/0] = [];
2298 // Rust currently will not evaluate the function `foo` at compile time
2299 fn foo() -> usize { 12 }
2300 const B: [u32; foo()] = [];
2302 // it is an error to try to add `u8` and `f64`
2304 const C: [u32; u8::MAX + f64::EPSILON] = [];
2309 Default impls for a trait must be located in the same crate where the trait was
2310 defined. For more information see the [opt-in builtin traits RFC](https://github
2311 .com/rust-lang/rfcs/blob/master/text/0019-opt-in-builtin-traits.md).
2315 The `Sized` trait is a special trait built-in to the compiler for types with a
2316 constant size known at compile-time. This trait is automatically implemented
2317 for types as needed by the compiler, and it is currently disallowed to
2318 explicitly implement it for a type.
2322 The types of any associated constants in a trait implementation must match the
2323 types in the trait definition. This error indicates that there was a mismatch.
2325 Here's an example of this error:
2335 const BAR: u32 = 5; // error, expected bool, found u32
2341 You cannot use associated items other than constant items as patterns. This
2342 includes method items. Example of erroneous code:
2348 fn bb() -> i32 { 0 }
2353 B::bb => {} // error: associated items in match patterns must
2359 Please check that you're not using a method as a pattern. Example:
2377 This error indicates that a binary assignment operator like `+=` or `^=` was
2378 applied to the wrong types. For example:
2382 x ^= true; // error, `^=` cannot be applied to types `u16` and `bool`
2383 x += (); // error, `+=` cannot be applied to types `u16` and `()`
2386 Another problem you might be facing is this: suppose you've overloaded the `+`
2387 operator for some type `Foo` by implementing the `std::ops::Add` trait for
2388 `Foo`, but you find that using `+=` does not work, as in this example:
2398 fn add(self, rhs: Foo) -> Foo {
2404 let mut x: Foo = Foo(5);
2405 x += Foo(7); // error, `+= cannot be applied to types `Foo` and `Foo`
2409 This is because the binary assignment operators currently do not work off of
2410 traits, so it is not possible to overload them. See [RFC 953] for a proposal
2413 [RFC 953]: https://github.com/rust-lang/rfcs/pull/953
2417 When `Trait2` is a subtrait of `Trait1` (for example, when `Trait2` has a
2418 definition like `trait Trait2: Trait1 { ... }`), it is not allowed to implement
2419 `Trait1` for `Trait2`. This is because `Trait2` already implements `Trait1` by
2420 definition, so it is not useful to do this.
2425 trait Foo { fn foo(&self) { } }
2429 impl Bar for Baz { } // error, `Baz` implements `Bar` by definition
2430 impl Foo for Baz { } // error, `Baz` implements `Bar` which implements `Foo`
2431 impl Baz for Baz { } // error, `Baz` (trivially) implements `Baz`
2432 impl Baz for Bar { } // Note: This is OK
2437 Trying to implement a trait for a trait object (as in `impl Trait1 for
2438 Trait2 { ... }`) does not work if the trait is not object-safe. Please see the
2439 [RFC 255] for more details on object safety rules.
2441 [RFC 255]: https://github.com/rust-lang/rfcs/pull/255
2445 Trait methods cannot be declared `const` by design. For more information, see
2448 [RFC 911]: https://github.com/rust-lang/rfcs/pull/911
2452 Default impls are only allowed for traits with no methods or associated items.
2453 For more information see the [opt-in builtin traits RFC](https://github.com/rust
2454 -lang/rfcs/blob/master/text/0019-opt-in-builtin-traits.md).
2458 This error indicates that some types or traits depend on each other
2459 and therefore cannot be constructed.
2461 The following example contains a circular dependency between two traits:
2464 trait FirstTrait : SecondTrait {
2468 trait SecondTrait : FirstTrait {
2475 This error indicates that a type or lifetime parameter has been declared
2476 but not actually used. Here is an example that demonstrates the error:
2484 If the type parameter was included by mistake, this error can be fixed
2485 by simply removing the type parameter, as shown below:
2493 Alternatively, if the type parameter was intentionally inserted, it must be
2494 used. A simple fix is shown below:
2502 This error may also commonly be found when working with unsafe code. For
2503 example, when using raw pointers one may wish to specify the lifetime for
2504 which the pointed-at data is valid. An initial attempt (below) causes this
2513 We want to express the constraint that Foo should not outlive `'a`, because
2514 the data pointed to by `T` is only valid for that lifetime. The problem is
2515 that there are no actual uses of `'a`. It's possible to work around this
2516 by adding a PhantomData type to the struct, using it to tell the compiler
2517 to act as if the struct contained a borrowed reference `&'a T`:
2520 use std::marker::PhantomData;
2522 struct Foo<'a, T: 'a> {
2524 phantom: PhantomData<&'a T>
2528 PhantomData can also be used to express information about unused type
2529 parameters. You can read more about it in the API documentation:
2531 https://doc.rust-lang.org/std/marker/struct.PhantomData.html
2536 register_diagnostics! {
2553 E0173, // manual implementations of unboxed closure traits are experimental
2554 E0174, // explicit use of unboxed closure methods are experimental
2557 E0187, // can't infer the kind of the closure
2558 E0188, // can not cast a immutable reference to a mutable pointer
2559 E0189, // deprecated: can only cast a boxed pointer to a boxed object
2560 E0190, // deprecated: can only cast a &-pointer to an &-object
2561 E0193, // cannot bound type where clause bounds may only be attached to types
2562 // involving type parameters
2564 E0196, // cannot determine a type for this closure
2565 E0203, // type parameter has more than one relaxed default bound,
2566 // and only one is supported
2568 E0209, // builtin traits can only be implemented on structs or enums
2569 E0212, // cannot extract an associated type from a higher-ranked trait bound
2570 E0213, // associated types are not accepted in this context
2571 E0214, // parenthesized parameters may only be used with a trait
2572 // E0215, // angle-bracket notation is not stable with `Fn`
2573 // E0216, // parenthetical notation is only stable with `Fn`
2574 E0217, // ambiguous associated type, defined in multiple supertraits
2575 E0218, // no associated type defined
2576 E0219, // associated type defined in higher-ranked supertrait
2577 E0221, // ambiguous associated type in bounds
2578 // E0222, // Error code E0045 (variadic function must have C calling
2579 // convention) duplicate
2580 E0224, // at least one non-builtin train is required for an object type
2581 E0226, // only a single explicit lifetime bound is permitted
2582 E0227, // ambiguous lifetime bound, explicit lifetime bound required
2583 E0228, // explicit lifetime bound required
2584 E0229, // associated type bindings are not allowed here
2585 E0230, // there is no type parameter on trait
2586 E0231, // only named substitution parameters are allowed
2589 E0235, // structure constructor specifies a structure of type but
2590 E0236, // no lang item for range syntax
2591 E0237, // no lang item for range syntax
2592 E0238, // parenthesized parameters may only be used with a trait
2593 E0239, // `next` method of `Iterator` trait has unexpected type
2596 E0242, // internal error looking up a definition
2597 E0245, // not a trait
2598 E0246, // invalid recursive type
2599 E0247, // found module name used as a type
2600 E0248, // found value name used as a type
2601 E0319, // trait impls for defaulted traits allowed just for structs/enums
2602 E0320, // recursive overflow during dropck
2603 E0321, // extended coherence rules for defaulted traits violated
2604 E0323, // implemented an associated const when another trait item expected
2605 E0324, // implemented a method when another trait item expected
2606 E0325, // implemented an associated type when another trait item expected
2607 E0328, // cannot implement Unsize explicitly
2608 E0329, // associated const depends on type parameter or Self.
2609 E0366, // dropck forbid specialization to concrete type or region
2610 E0367, // dropck forbid specialization to predicate not in struct/enum
2611 E0369, // binary operation `<op>` cannot be applied to types
2612 E0370, // discriminant overflow
2613 E0374, // the trait `CoerceUnsized` may only be implemented for a coercion
2614 // between structures with one field being coerced, none found
2615 E0375, // the trait `CoerceUnsized` may only be implemented for a coercion
2616 // between structures with one field being coerced, but multiple
2617 // fields need coercions
2618 E0376, // the trait `CoerceUnsized` may only be implemented for a coercion
2619 // between structures
2620 E0377, // the trait `CoerceUnsized` may only be implemented for a coercion
2621 // between structures with the same definition
2622 E0390, // only a single inherent implementation marked with
2623 // `#[lang = \"{}\"]` is allowed for the `{}` primitive
2624 E0393, // the type parameter `{}` must be explicitly specified in an object
2625 // type because its default value `{}` references the type `Self`"
2626 E0399, // trait items need to be implemented because the associated
2627 // type `{}` was overridden
2628 E0436 // functional record update requires a struct