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 When matching against a range, the compiler verifies that the range is
174 non-empty. Range patterns include both end-points, so this is equivalent to
175 requiring the start of the range to be less than or equal to the end of the
182 // This range is ok, albeit pointless.
184 // This range is empty, and the compiler can tell.
191 This error indicates that a pointer to a trait type cannot be implicitly
192 dereferenced by a pattern. Every trait defines a type, but because the
193 size of trait implementors isn't fixed, this type has no compile-time size.
194 Therefore, all accesses to trait types must be through pointers. If you
195 encounter this error you should try to avoid dereferencing the pointer.
198 let trait_obj: &SomeTrait = ...;
200 // This tries to implicitly dereference to create an unsized local variable.
201 let &invalid = trait_obj;
203 // You can call methods without binding to the value being pointed at.
204 trait_obj.method_one();
205 trait_obj.method_two();
208 You can read more about trait objects in the Trait Object section of the
211 http://doc.rust-lang.org/reference.html#trait-objects
215 It is not allowed to manually call destructors in Rust. It is also not
216 necessary to do this since `drop` is called automatically whenever a value goes
219 Here's an example of this error:
233 let mut x = Foo { x: -7 };
234 x.drop(); // error: explicit use of destructor method
240 When trying to make some type implement a trait `Foo`, you must, at minimum,
241 provide implementations for all of `Foo`'s required methods (meaning the
242 methods that do not have default implementations), as well as any required
243 trait items like associated types or constants.
247 This error indicates that an attempted implementation of a trait method
248 has the wrong number of type parameters.
250 For example, the trait below has a method `foo` with a type parameter `T`,
251 but the implementation of `foo` for the type `Bar` is missing this parameter:
255 fn foo<T: Default>(x: T) -> Self;
260 // error: method `foo` has 0 type parameters but its trait declaration has 1
263 fn foo(x: bool) -> Self { Bar }
269 This error indicates that an attempted implementation of a trait method
270 has the wrong number of function parameters.
272 For example, the trait below has a method `foo` with two function parameters
273 (`&self` and `u8`), but the implementation of `foo` for the type `Bar` omits
278 fn foo(&self, x: u8) -> bool;
283 // error: method `foo` has 1 parameter but the declaration in trait `Foo::foo`
286 fn foo(&self) -> bool { true }
292 The parameters of any trait method must match between a trait implementation
293 and the trait definition.
295 Here are a couple examples of this error:
306 // error, expected u16, found i16
309 // error, values differ in mutability
310 fn bar(&mut self) { }
316 It is not allowed to cast to a bool. If you are trying to cast a numeric type
317 to a bool, you can compare it with zero instead:
323 let x_is_nonzero = x != 0;
325 // Not allowed, won't compile
326 let x_is_nonzero = x as bool;
331 During a method call, a value is automatically dereferenced as many times as
332 needed to make the value's type match the method's receiver. The catch is that
333 the compiler will only attempt to dereference a number of times up to the
334 recursion limit (which can be set via the `recursion_limit` attribute).
336 For a somewhat artificial example:
339 #![recursion_limit="2"]
351 // error, reached the recursion limit while auto-dereferencing &&Foo
356 One fix may be to increase the recursion limit. Note that it is possible to
357 create an infinite recursion of dereferencing, in which case the only fix is to
358 somehow break the recursion.
362 When invoking closures or other implementations of the function traits `Fn`,
363 `FnMut` or `FnOnce` using call notation, the number of parameters passed to the
364 function must match its definition.
366 An example using a closure:
370 let a = f(); // invalid, too few parameters
371 let b = f(4); // this works!
372 let c = f(2, 3); // invalid, too many parameters
375 A generic function must be treated similarly:
378 fn foo<F: Fn()>(f: F) {
379 f(); // this is valid, but f(3) would not work
385 The built-in function traits are generic over a tuple of the function arguments.
386 If one uses angle-bracket notation (`Fn<(T,), Output=U>`) instead of parentheses
387 (`Fn(T) -> U`) to denote the function trait, the type parameter should be a
388 tuple. Otherwise function call notation cannot be used and the trait will not be
389 implemented by closures.
391 The most likely source of this error is using angle-bracket notation without
392 wrapping the function argument type into a tuple, for example:
395 fn foo<F: Fn<i32>>(f: F) -> F::Output { f(3) }
398 It can be fixed by adjusting the trait bound like this:
401 fn foo<F: Fn<(i32,)>>(f: F) -> F::Output { f(3) }
404 Note that `(T,)` always denotes the type of a 1-tuple containing an element of
405 type `T`. The comma is necessary for syntactic disambiguation.
409 External C functions are allowed to be variadic. However, a variadic function
410 takes a minimum number of arguments. For example, consider C's variadic `printf`
415 use libc::{ c_char, c_int };
418 fn printf(_: *const c_char, ...) -> c_int;
422 Using this declaration, it must be called with at least one argument, so
423 simply calling `printf()` is illegal. But the following uses are allowed:
427 use std::ffi::CString;
429 printf(CString::new("test\n").unwrap().as_ptr());
430 printf(CString::new("number = %d\n").unwrap().as_ptr(), 3);
431 printf(CString::new("%d, %d\n").unwrap().as_ptr(), 10, 5);
437 The number of arguments passed to a function must match the number of arguments
438 specified in the function signature.
440 For example, a function like
443 fn f(a: u16, b: &str) {}
446 must always be called with exactly two arguments, e.g. `f(2, "test")`.
448 Note, that Rust does not have a notion of optional function arguments or
449 variadic functions (except for its C-FFI).
453 This error indicates that during an attempt to build a struct or struct-like
454 enum variant, one of the fields was specified more than once. Each field should
455 be specified exactly one time.
459 This error indicates that during an attempt to build a struct or struct-like
460 enum variant, one of the fields was not provided. Each field should be
461 specified exactly once.
465 Box placement expressions (like C++'s "placement new") do not yet support any
466 place expression except the exchange heap (i.e. `std::boxed::HEAP`).
467 Furthermore, the syntax is changing to use `in` instead of `box`. See [RFC 470]
468 and [RFC 809] for more details.
470 [RFC 470]: https://github.com/rust-lang/rfcs/pull/470
471 [RFC 809]: https://github.com/rust-lang/rfcs/pull/809
475 The left-hand side of a compound assignment expression must be an lvalue
476 expression. An lvalue expression represents a memory location and includes
477 item paths (ie, namespaced variables), dereferences, indexing expressions,
478 and field references.
480 Let's start with some bad examples:
482 use std::collections::LinkedList;
484 // Bad: assignment to non-lvalue expression
485 LinkedList::new() += 1;
489 fn some_func(i: &mut i32) {
490 i += 12; // Error : '+=' operation cannot be applied on a reference !
493 And now some good examples:
501 fn some_func(i: &mut i32) {
509 The compiler found a function whose body contains a `return;` statement but
510 whose return type is not `()`. An example of this is:
519 Since `return;` is just like `return ();`, there is a mismatch between the
520 function's return type and the value being returned.
524 The left-hand side of an assignment operator must be an lvalue expression. An
525 lvalue expression represents a memory location and can be a variable (with
526 optional namespacing), a dereference, an indexing expression or a field
529 More details can be found here:
530 https://doc.rust-lang.org/reference.html#lvalues,-rvalues-and-temporaries
532 Now, we can go further. Here are some bad examples:
538 const SOME_CONST : i32 = 12;
540 fn some_other_func() {}
543 SOME_CONST = 14; // error : a constant value cannot be changed!
544 1 = 3; // error : 1 isn't a valid lvalue!
545 some_other_func() = 4; // error : we can't assign value to a function!
546 SomeStruct.x = 12; // error : SomeStruct a structure name but it is used
551 And now let's give good examples:
558 let mut s = SomeStruct {x: 0, y: 0};
560 s.x = 3; // that's good !
564 fn some_func(x: &mut i32) {
565 *x = 12; // that's good !
571 When defining a recursive struct or enum, any use of the type being defined
572 from inside the definition must occur behind a pointer (like `Box` or `&`).
573 This is because structs and enums must have a well-defined size, and without
574 the pointer the size of the type would need to be unbounded.
576 Consider the following erroneous definition of a type for a list of bytes:
579 // error, illegal recursive struct type
582 tail: Option<ListNode>,
586 This type cannot have a well-defined size, because it needs to be arbitrarily
587 large (since we would be able to nest `ListNode`s to any depth). Specifically,
589 size of `ListNode` = 1 byte for `head`
590 + 1 byte for the discriminant of the `Option`
593 One way to fix this is by wrapping `ListNode` in a `Box`, like so:
598 tail: Option<Box<ListNode>>,
602 This works because `Box` is a pointer, so its size is well-known.
606 You cannot define a struct (or enum) `Foo` that requires an instance of `Foo`
607 in order to make a new `Foo` value. This is because there would be no way a
608 first instance of `Foo` could be made to initialize another instance!
610 Here's an example of a struct that has this problem:
613 struct Foo { x: Box<Foo> } // error
616 One fix is to use `Option`, like so:
619 struct Foo { x: Option<Box<Foo>> }
622 Now it's possible to create at least one instance of `Foo`: `Foo { x: None }`.
626 Enum discriminants are used to differentiate enum variants stored in memory.
627 This error indicates that the same value was used for two or more variants,
628 making them impossible to tell apart.
646 Note that variants without a manually specified discriminant are numbered from
647 top to bottom starting from 0, so clashes can occur with seemingly unrelated
657 Here `X` will have already been assigned the discriminant 0 by the time `Y` is
658 encountered, so a conflict occurs.
662 The default type for enum discriminants is `isize`, but it can be adjusted by
663 adding the `repr` attribute to the enum declaration. This error indicates that
664 an integer literal given as a discriminant is not a member of the discriminant
675 Here, 1024 lies outside the valid range for `u8`, so the discriminant for `A` is
676 invalid. You may want to change representation types to fix this, or else change
677 invalid discriminant values so that they fit within the existing type.
679 Note also that without a representation manually defined, the compiler will
680 optimize by using the smallest integer type possible.
684 At present, it's not possible to define a custom representation for an enum with
685 a single variant. As a workaround you can add a `Dummy` variant.
687 See: https://github.com/rust-lang/rust/issues/10292
691 It is impossible to define an integer type to be used to represent zero-variant
692 enum values because there are no zero-variant enum values. There is no way to
693 construct an instance of the following type using only safe code:
701 Too many type parameters were supplied for a function. For example:
707 foo::<f64, bool>(); // error, expected 1 parameter, found 2 parameters
711 The number of supplied parameters much exactly match the number of defined type
716 Not enough type parameters were supplied for a function. For example:
722 foo::<f64>(); // error, expected 2 parameters, found 1 parameter
726 Note that if a function takes multiple type parameters but you want the compiler
727 to infer some of them, you can use type placeholders:
730 fn foo<T, U>(x: T) {}
734 foo::<f64>(x); // error, expected 2 parameters, found 1 parameter
735 foo::<_, f64>(x); // same as `foo::<bool, f64>(x)`
741 This error indicates that a lifetime is missing from a type. If it is an error
742 inside a function signature, the problem may be with failing to adhere to the
743 lifetime elision rules (see below).
745 Here are some simple examples of where you'll run into this error:
748 struct Foo { x: &bool } // error
749 struct Foo<'a> { x: &'a bool } // correct
751 enum Bar { A(u8), B(&bool), } // error
752 enum Bar<'a> { A(u8), B(&'a bool), } // correct
754 type MyStr = &str; // error
755 type MyStr<'a> = &'a str; //correct
759 Lifetime elision is a special, limited kind of inference for lifetimes in
760 function signatures which allows you to leave out lifetimes in certain cases.
761 For more background on lifetime elision see [the book][book-le].
763 The lifetime elision rules require that any function signature with an elided
764 output lifetime must either have
766 - exactly one input lifetime
767 - or, multiple input lifetimes, but the function must also be a method with a
768 `&self` or `&mut self` receiver
770 In the first case, the output lifetime is inferred to be the same as the unique
771 input lifetime. In the second case, the lifetime is instead inferred to be the
772 same as the lifetime on `&self` or `&mut self`.
774 Here are some examples of elision errors:
777 // error, no input lifetimes
778 fn foo() -> &str { ... }
780 // error, `x` and `y` have distinct lifetimes inferred
781 fn bar(x: &str, y: &str) -> &str { ... }
783 // error, `y`'s lifetime is inferred to be distinct from `x`'s
784 fn baz<'a>(x: &'a str, y: &str) -> &str { ... }
787 [book-le]: http://doc.rust-lang.org/nightly/book/lifetimes.html#lifetime-elision
791 This error means that an incorrect number of lifetime parameters were provided
792 for a type (like a struct or enum) or trait.
794 Some basic examples include:
797 struct Foo<'a>(&'a str);
801 foo: Foo, // error: expected 1, found 0
802 bar: Bar<'a>, // error: expected 0, found 1
806 Here's an example that is currently an error, but may work in a future version
810 struct Foo<'a>(&'a str);
813 impl Quux for Foo { } // error: expected 1, found 0
816 Lifetime elision in implementation headers was part of the lifetime elision
817 RFC. It is, however, [currently unimplemented][iss15872].
819 [iss15872]: https://github.com/rust-lang/rust/issues/15872
823 You can only define an inherent implementation for a type in the same crate
824 where the type was defined. For example, an `impl` block as below is not allowed
825 since `Vec` is defined in the standard library:
828 impl Vec<u8> { ... } // error
831 To fix this problem, you can do either of these things:
833 - define a trait that has the desired associated functions/types/constants and
834 implement the trait for the type in question
835 - define a new type wrapping the type and define an implementation on the new
838 Note that using the `type` keyword does not work here because `type` only
839 introduces a type alias:
842 type Bytes = Vec<u8>;
844 impl Bytes { ... } // error, same as above
849 In order to be consistent with Rust's lack of global type inference, type
850 placeholders are disallowed by design in item signatures.
852 Examples of this error include:
855 fn foo() -> _ { 5 } // error, explicitly write out the return type instead
857 static BAR: _ = "test"; // error, explicitly write out the type instead
862 It is not possible to define `main` with type parameters, or even with function
863 parameters. When `main` is present, it must take no arguments and return `()`.
867 It is not possible to declare type parameters on a function that has the `start`
868 attribute. Such a function must have the following type signature:
871 fn(isize, *const *const u8) -> isize
876 This error means that the compiler found a return expression in a function
877 marked as diverging. A function diverges if it has `!` in the place of the
878 return type in its signature. For example:
881 fn foo() -> ! { return; } // error
884 For a function that diverges, every control path in the function must never
885 return, for example with a `loop` that never breaks or a call to another
886 diverging function (such as `panic!()`).
890 In types, the `+` type operator has low precedence, so it is often necessary
899 w: &'a Foo + Copy, // error, use &'a (Foo + Copy)
900 x: &'a Foo + 'a, // error, use &'a (Foo + 'a)
901 y: &'a mut Foo + 'a, // error, use &'a mut (Foo + 'a)
902 z: fn() -> Foo + 'a, // error, use fn() -> (Foo + 'a)
906 More details can be found in [RFC 438].
908 [RFC 438]: https://github.com/rust-lang/rfcs/pull/438
912 Explicitly implementing both Drop and Copy for a type is currently disallowed.
913 This feature can make some sense in theory, but the current implementation is
914 incorrect and can lead to memory unsafety (see [issue #20126][iss20126]), so
915 it has been disabled for now.
917 [iss20126]: https://github.com/rust-lang/rust/issues/20126
921 An associated function for a trait was defined to be static, but an
922 implementation of the trait declared the same function to be a method (i.e. to
923 take a `self` parameter).
925 Here's an example of this error:
935 // error, method `foo` has a `&self` declaration in the impl, but not in
942 An associated function for a trait was defined to be a method (i.e. to take a
943 `self` parameter), but an implementation of the trait declared the same function
946 Here's an example of this error:
956 // error, method `foo` has a `&self` declaration in the trait, but not in
963 Negative impls are only allowed for traits with default impls. For more
964 information see the [opt-in builtin traits RFC](https://github.com/rust-lang/
965 rfcs/blob/master/text/0019-opt-in-builtin-traits.md).
969 Inherent implementations (one that do not implement a trait but provide
970 methods associated with a type) are always safe because they are not
971 implementing an unsafe trait. Removing the `unsafe` keyword from the inherent
972 implementation will resolve this error.
977 // this will cause this error
979 // converting it to this will fix it
986 A negative implementation is one that excludes a type from implementing a
987 particular trait. Not being able to use a trait is always a safe operation,
988 so negative implementations are always safe and never need to be marked as
994 // unsafe is unnecessary
995 unsafe impl !Clone for Foo { }
997 impl !Clone for Foo { }
1003 Safe traits should not have unsafe implementations, therefore marking an
1004 implementation for a safe trait unsafe will cause a compiler error. Removing the
1005 unsafe marker on the trait noted in the error will resolve this problem.
1012 // this won't compile because Bar is safe
1013 unsafe impl Bar for Foo { }
1014 // this will compile
1015 impl Bar for Foo { }
1021 Unsafe traits must have unsafe implementations. This error occurs when an
1022 implementation for an unsafe trait isn't marked as unsafe. This may be resolved
1023 by marking the unsafe implementation as unsafe.
1028 unsafe trait Bar { }
1030 // this won't compile because Bar is unsafe and impl isn't unsafe
1031 impl Bar for Foo { }
1032 // this will compile
1033 unsafe impl Bar for Foo { }
1039 It is an error to define an associated function more than once.
1047 fn bar(&self) -> bool { self.0 > 5 }
1049 // error: duplicate associated function
1054 fn baz(&self) -> bool;
1058 fn baz(&self) -> bool { true }
1060 // error: duplicate method
1061 fn baz(&self) -> bool { self.0 > 5 }
1067 Inherent associated types were part of [RFC 195] but are not yet implemented.
1068 See [the tracking issue][iss8995] for the status of this implementation.
1070 [RFC 195]: https://github.com/rust-lang/rfcs/pull/195
1071 [iss8995]: https://github.com/rust-lang/rust/issues/8995
1075 An attempt to implement the `Copy` trait for a struct failed because one of the
1076 fields does not implement `Copy`. To fix this, you must implement `Copy` for the
1077 mentioned field. Note that this may not be possible, as in the example of
1084 impl Copy for Foo { }
1087 This fails because `Vec<T>` does not implement `Copy` for any `T`.
1089 Here's another example that will fail:
1098 This fails because `&mut T` is not `Copy`, even when `T` is `Copy` (this
1099 differs from the behavior for `&T`, which is always `Copy`).
1103 An attempt to implement the `Copy` trait for an enum failed because one of the
1104 variants does not implement `Copy`. To fix this, you must implement `Copy` for
1105 the mentioned variant. Note that this may not be possible, as in the example of
1113 impl Copy for Foo { }
1116 This fails because `Vec<T>` does not implement `Copy` for any `T`.
1118 Here's another example that will fail:
1128 This fails because `&mut T` is not `Copy`, even when `T` is `Copy` (this
1129 differs from the behavior for `&T`, which is always `Copy`).
1133 You can only implement `Copy` for a struct or enum. Both of the following
1134 examples will fail, because neither `i32` (primitive type) nor `&'static Bar`
1135 (reference to `Bar`) is a struct or enum:
1139 impl Copy for Foo { } // error
1141 #[derive(Copy, Clone)]
1143 impl Copy for &'static Bar { } // error
1148 This error indicates that not enough type parameters were found in a type or
1151 For example, the `Foo` struct below is defined to be generic in `T`, but the
1152 type parameter is missing in the definition of `Bar`:
1155 struct Foo<T> { x: T }
1157 struct Bar { x: Foo }
1162 This error indicates that too many type parameters were found in a type or
1165 For example, the `Foo` struct below has no type parameters, but is supplied
1166 with two in the definition of `Bar`:
1169 struct Foo { x: bool }
1171 struct Bar<S, T> { x: Foo<S, T> }
1176 This error indicates a constant expression for the array length was found, but
1177 it was not an integer (signed or unsigned) expression.
1179 Some examples of code that produces this error are:
1182 const A: [u32; "hello"] = []; // error
1183 const B: [u32; true] = []; // error
1184 const C: [u32; 0.0] = []; // error
1188 There was an error while evaluating the expression for the length of a fixed-
1191 Some examples of this error are:
1194 // divide by zero in the length expression
1195 const A: [u32; 1/0] = [];
1197 // Rust currently will not evaluate the function `foo` at compile time
1198 fn foo() -> usize { 12 }
1199 const B: [u32; foo()] = [];
1201 // it is an error to try to add `u8` and `f64`
1203 const C: [u32; u8::MAX + f64::EPSILON] = [];
1208 Default impls for a trait must be located in the same crate where the trait was
1209 defined. For more information see the [opt-in builtin traits RFC](https://github
1210 .com/rust-lang/rfcs/blob/master/text/0019-opt-in-builtin-traits.md).
1214 The `Sized` trait is a special trait built-in to the compiler for types with a
1215 constant size known at compile-time. This trait is automatically implemented
1216 for types as needed by the compiler, and it is currently disallowed to
1217 explicitly implement it for a type.
1221 The types of any associated constants in a trait implementation must match the
1222 types in the trait definition. This error indicates that there was a mismatch.
1224 Here's an example of this error:
1234 const BAR: u32 = 5; // error, expected bool, found u32
1240 This error indicates that a binary assignment operator like `+=` or `^=` was
1241 applied to the wrong types. For example:
1245 x ^= true; // error, `^=` cannot be applied to types `u16` and `bool`
1246 x += (); // error, `+=` cannot be applied to types `u16` and `()`
1249 Another problem you might be facing is this: suppose you've overloaded the `+`
1250 operator for some type `Foo` by implementing the `std::ops::Add` trait for
1251 `Foo`, but you find that using `+=` does not work, as in this example:
1261 fn add(self, rhs: Foo) -> Foo {
1267 let mut x: Foo = Foo(5);
1268 x += Foo(7); // error, `+= cannot be applied to types `Foo` and `Foo`
1272 This is because the binary assignment operators currently do not work off of
1273 traits, so it is not possible to overload them. See [RFC 953] for a proposal
1276 [RFC 953]: https://github.com/rust-lang/rfcs/pull/953
1280 When `Trait2` is a subtrait of `Trait1` (for example, when `Trait2` has a
1281 definition like `trait Trait2: Trait1 { ... }`), it is not allowed to implement
1282 `Trait1` for `Trait2`. This is because `Trait2` already implements `Trait1` by
1283 definition, so it is not useful to do this.
1288 trait Foo { fn foo(&self) { } }
1292 impl Bar for Baz { } // error, `Baz` implements `Bar` by definition
1293 impl Foo for Baz { } // error, `Baz` implements `Bar` which implements `Foo`
1294 impl Baz for Baz { } // error, `Baz` (trivially) implements `Baz`
1295 impl Baz for Bar { } // Note: This is OK
1300 Trying to implement a trait for a trait object (as in `impl Trait1 for
1301 Trait2 { ... }`) does not work if the trait is not object-safe. Please see the
1302 [RFC 255] for more details on object safety rules.
1304 [RFC 255]: https://github.com/rust-lang/rfcs/pull/255
1308 Trait methods cannot be declared `const` by design. For more information, see
1311 [RFC 911]: https://github.com/rust-lang/rfcs/pull/911
1315 Default impls are only allowed for traits with no methods or associated items.
1316 For more information see the [opt-in builtin traits RFC](https://github.com/rust
1317 -lang/rfcs/blob/master/text/0019-opt-in-builtin-traits.md).
1322 register_diagnostics! {
1323 E0034, // multiple applicable methods in scope
1324 E0035, // does not take type parameters
1325 E0036, // incorrect number of type parameters given for this method
1326 E0044, // foreign items may not have type parameters
1327 E0045, // variadic function must have C calling convention
1364 E0173, // manual implementations of unboxed closure traits are experimental
1365 E0174, // explicit use of unboxed closure methods are experimental
1368 E0187, // can't infer the kind of the closure
1369 E0188, // can not cast a immutable reference to a mutable pointer
1370 E0189, // deprecated: can only cast a boxed pointer to a boxed object
1371 E0190, // deprecated: can only cast a &-pointer to an &-object
1372 E0191, // value of the associated type must be specified
1373 E0193, // cannot bound type where clause bounds may only be attached to types
1374 // involving type parameters
1376 E0195, // lifetime parameters or bounds on method do not match the trait declaration
1377 E0196, // cannot determine a type for this closure
1378 E0203, // type parameter has more than one relaxed default bound,
1379 // and only one is supported
1380 E0207, // type parameter is not constrained by the impl trait, self type, or predicate
1382 E0209, // builtin traits can only be implemented on structs or enums
1383 E0210, // type parameter is not constrained by any local type
1385 E0212, // cannot extract an associated type from a higher-ranked trait bound
1386 E0213, // associated types are not accepted in this context
1387 E0214, // parenthesized parameters may only be used with a trait
1388 E0215, // angle-bracket notation is not stable with `Fn`
1389 E0216, // parenthetical notation is only stable with `Fn`
1390 E0217, // ambiguous associated type, defined in multiple supertraits
1391 E0218, // no associated type defined
1392 E0219, // associated type defined in higher-ranked supertrait
1393 E0220, // associated type not found for type parameter
1394 E0221, // ambiguous associated type in bounds
1395 E0222, // variadic function must have C calling convention
1396 E0223, // ambiguous associated type
1397 E0224, // at least one non-builtin train is required for an object type
1398 E0225, // only the builtin traits can be used as closure or object bounds
1399 E0226, // only a single explicit lifetime bound is permitted
1400 E0227, // ambiguous lifetime bound, explicit lifetime bound required
1401 E0228, // explicit lifetime bound required
1402 E0229, // associated type bindings are not allowed here
1403 E0230, // there is no type parameter on trait
1404 E0231, // only named substitution parameters are allowed
1405 E0232, // this attribute must have a value
1408 E0235, // structure constructor specifies a structure of type but
1409 E0236, // no lang item for range syntax
1410 E0237, // no lang item for range syntax
1411 E0238, // parenthesized parameters may only be used with a trait
1412 E0239, // `next` method of `Iterator` trait has unexpected type
1415 E0242, // internal error looking up a definition
1416 E0245, // not a trait
1417 E0246, // illegal recursive type
1418 E0247, // found module name used as a type
1419 E0248, // found value name used as a type
1420 E0319, // trait impls for defaulted traits allowed just for structs/enums
1421 E0320, // recursive overflow during dropck
1422 E0321, // extended coherence rules for defaulted traits violated
1423 E0323, // implemented an associated const when another trait item expected
1424 E0324, // implemented a method when another trait item expected
1425 E0325, // implemented an associated type when another trait item expected
1426 E0327, // referred to method instead of constant in match pattern
1427 E0328, // cannot implement Unsize explicitly
1428 E0329, // associated const depends on type parameter or Self.
1429 E0366, // dropck forbid specialization to concrete type or region
1430 E0367, // dropck forbid specialization to predicate not in struct/enum
1431 E0369, // binary operation `<op>` cannot be applied to types
1432 E0374, // the trait `CoerceUnsized` may only be implemented for a coercion
1433 // between structures with one field being coerced, none found
1434 E0375, // the trait `CoerceUnsized` may only be implemented for a coercion
1435 // between structures with one field being coerced, but multiple
1436 // fields need coercions
1437 E0376, // the trait `CoerceUnsized` may only be implemented for a coercion
1438 // between structures
1439 E0377, // the trait `CoerceUnsized` may only be implemented for a coercion
1440 // between structures with the same definition
1441 E0390, // only a single inherent implementation marked with
1442 // `#[lang = \"{}\"]` is allowed for the `{}` primitive
1443 E0391, // unsupported cyclic reference between types/traits detected
1444 E0392, // parameter `{}` is never used
1445 E0393 // the type parameter `{}` must be explicitly specified in an object
1446 // type because its default value `{}` references the type `Self`"