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 // Error messages for EXXXX errors.
14 // Each message should start and end with a new line, and be wrapped to 80 characters.
15 // In vim you can `:set tw=80` and use `gq` to wrap paragraphs. Use `:set tw=0` to disable.
16 register_long_diagnostics! {
19 This error suggests that the expression arm corresponding to the noted pattern
20 will never be reached as for all possible values of the expression being
21 matched, one of the preceding patterns will match.
23 This means that perhaps some of the preceding patterns are too general, this one
24 is too specific or the ordering is incorrect.
28 This error indicates that an empty match expression is illegal because the type
29 it is matching on is non-empty (there exist values of this type). In safe code
30 it is impossible to create an instance of an empty type, so empty match
31 expressions are almost never desired. This error is typically fixed by adding
32 one or more cases to the match expression.
34 An example of an empty type is `enum Empty { }`.
38 Not-a-Number (NaN) values cannot be compared for equality and hence can never
39 match the input to a match expression. To match against NaN values, you should
40 instead use the `is_nan` method in a guard, as in: `x if x.is_nan() => ...`
44 This error indicates that the compiler cannot guarantee a matching pattern for
45 one or more possible inputs to a match expression. Guaranteed matches are
46 required in order to assign values to match expressions, or alternatively,
47 determine the flow of execution.
49 If you encounter this error you must alter your patterns so that every possible
50 value of the input type is matched. For types with a small number of variants
51 (like enums) you should probably cover all cases explicitly. Alternatively, the
52 underscore `_` wildcard pattern can be added after all other patterns to match
56 // FIXME: Remove duplication here?
58 Patterns used to bind names must be irrefutable, that is, they must guarantee
59 that a name will be extracted in all cases. If you encounter this error you
60 probably need to use a `match` or `if let` to deal with the possibility of
65 Patterns used to bind names must be irrefutable, that is, they must guarantee
66 that a name will be extracted in all cases. If you encounter this error you
67 probably need to use a `match` or `if let` to deal with the possibility of
72 This error indicates that the bindings in a match arm would require a value to
73 be moved into more than one location, thus violating unique ownership. Code like
74 the following is invalid as it requires the entire `Option<String>` to be moved
75 into a variable called `op_string` while simultaneously requiring the inner
76 String to be moved into a variable called `s`.
79 let x = Some("s".to_string());
81 op_string @ Some(s) => ...
90 Names bound in match arms retain their type in pattern guards. As such, if a
91 name is bound by move in a pattern, it should also be moved to wherever it is
92 referenced in the pattern guard code. Doing so however would prevent the name
93 from being available in the body of the match arm. Consider the following:
96 match Some("hi".to_string()) {
97 Some(s) if s.len() == 0 => // use s.
102 The variable `s` has type `String`, and its use in the guard is as a variable of
103 type `String`. The guard code effectively executes in a separate scope to the
104 body of the arm, so the value would be moved into this anonymous scope and
105 therefore become unavailable in the body of the arm. Although this example seems
106 innocuous, the problem is most clear when considering functions that take their
110 match Some("hi".to_string()) {
111 Some(s) if { drop(s); false } => (),
117 The value would be dropped in the guard then become unavailable not only in the
118 body of that arm but also in all subsequent arms! The solution is to bind by
119 reference when using guards or refactor the entire expression, perhaps by
120 putting the condition inside the body of the arm.
124 In a pattern, all values that don't implement the `Copy` trait have to be bound
125 the same way. The goal here is to avoid binding simultaneously by-move and
128 This limitation may be removed in a future version of Rust.
135 let x = Some((X { x: () }, X { x: () }));
137 Some((y, ref z)) => {},
142 You have two solutions:
144 Solution #1: Bind the pattern's values the same way.
149 let x = Some((X { x: () }, X { x: () }));
151 Some((ref y, ref z)) => {},
152 // or Some((y, z)) => {}
157 Solution #2: Implement the `Copy` trait for the `X` structure.
159 However, please keep in mind that the first solution should be preferred.
162 #[derive(Clone, Copy)]
165 let x = Some((X { x: () }, X { x: () }));
167 Some((y, ref z)) => {},
174 The value of statics and constants must be known at compile time, and they live
175 for the entire lifetime of a program. Creating a boxed value allocates memory on
176 the heap at runtime, and therefore cannot be done at compile time.
180 Initializers for constants and statics are evaluated at compile time.
181 User-defined operators rely on user-defined functions, which cannot be evaluated
191 impl Index<u8> for Foo {
194 fn index<'a>(&'a self, idx: u8) -> &'a u8 { &self.a }
197 const a: Foo = Foo { a: 0u8 };
198 const b: u8 = a[0]; // Index trait is defined by the user, bad!
201 Only operators on builtin types are allowed.
206 const a: &'static [i32] = &[1, 2, 3];
207 const b: i32 = a[0]; // Good!
212 Static and const variables can refer to other const variables. But a const
213 variable cannot refer to a static variable. For example, `Y` cannot refer to `X`
221 To fix this, the value can be extracted as a const and then used:
231 Constants can only be initialized by a constant value or, in a future
232 version of Rust, a call to a const function. This error indicates the use
233 of a path (like a::b, or x) denoting something other than one of these
234 allowed items. Example:
237 const FOO: i32 = { let x = 0; x }; // 'x' isn't a constant nor a function!
240 To avoid it, you have to replace the non-constant value:
243 const FOO: i32 = { const X : i32 = 0; X };
245 const FOO: i32 = { 0 }; // but brackets are useless here
250 The only functions that can be called in static or constant expressions are
251 `const` functions. Rust currently does not support more general compile-time
254 See [RFC 911] for more details on the design of `const fn`s.
256 [RFC 911]: https://github.com/rust-lang/rfcs/blob/master/text/0911-const-fn.md
260 Blocks in constants may only contain items (such as constant, function
261 definition, etc...) and a tail expression. Example:
264 const FOO: i32 = { let x = 0; x }; // 'x' isn't an item!
267 To avoid it, you have to replace the non-item object:
270 const FOO: i32 = { const X : i32 = 0; X };
275 The value of static and const variables must be known at compile time. You
276 can't cast a pointer as an integer because we can't know what value the
279 However, pointers to other constants' addresses are allowed in constants,
284 const Y: *const u32 = &X;
287 Therefore, casting one of these non-constant pointers to an integer results
288 in a non-constant integer which lead to this error. Example:
292 const Y: usize = &X as *const u32 as usize;
298 A function call isn't allowed in the const's initialization expression
299 because the expression's value must be known at compile-time. Example of
308 fn test(&self) -> i32 {
314 const FOO: Test = Test::V1;
316 const A: i32 = FOO.test(); // You can't call Test::func() here !
320 Remember: you can't use a function call inside a const's initialization
321 expression! However, you can totally use it elsewhere you want:
325 const FOO: Test = Test::V1;
327 FOO.func(); // here is good
328 let x = FOO.func(); // or even here!
334 This error indicates that an attempt was made to divide by zero (or take the
335 remainder of a zero divisor) in a static or constant expression.
339 Enum variants which contain no data can be given a custom integer
340 representation. This error indicates that the value provided is not an
341 integer literal and is therefore invalid.
345 This error indicates that the compiler was unable to sensibly evaluate an
346 integer expression provided as an enum discriminant. Attempting to divide by 0
347 or causing integer overflow are two ways to induce this error. For example:
356 Ensure that the expressions given can be evaluated as the desired integer type.
357 See the FFI section of the Reference for more information about using a custom
360 https://doc.rust-lang.org/reference.html#ffi-attributes
364 You tried to give a type parameter to a type which doesn't need it. Erroneous
368 type X = u32<i32>; // error: type parameters are not allowed on this type
371 Please check that you used the correct type and recheck its definition. Perhaps
372 it doesn't need the type parameter.
381 You tried to give a lifetime parameter to a type which doesn't need it.
382 Erroneous code example:
385 type X = u32<'static>; // error: lifetime parameters are not allowed on
389 Please check that you used the correct type and recheck its definition,
390 perhaps it doesn't need the lifetime parameter. Example:
398 Using unsafe functionality, such as dereferencing raw pointers and calling
399 functions via FFI or marked as unsafe, is potentially dangerous and disallowed
400 by safety checks. These safety checks can be relaxed for a section of the code
401 by wrapping the unsafe instructions with an `unsafe` block. For instance:
404 unsafe fn f() { return; }
411 See also https://doc.rust-lang.org/book/unsafe.html
415 This error indicates that the compiler found multiple functions with the
416 `#[main]` attribute. This is an error because there must be a unique entry
417 point into a Rust program.
421 Lang items are already implemented in the standard library. Unless you are
422 writing a free-standing application (e.g. a kernel), you do not need to provide
425 You can build a free-standing crate by adding `#![no_std]` to the crate
433 See also https://doc.rust-lang.org/book/no-stdlib.html
437 `const` and `static` mean different things. A `const` is a compile-time
438 constant, an alias for a literal value. This property means you can match it
439 directly within a pattern.
441 The `static` keyword, on the other hand, guarantees a fixed location in memory.
442 This does not always mean that the value is constant. For example, a global
443 mutex can be declared `static` as well.
445 If you want to match against a `static`, consider using a guard instead:
448 static FORTY_TWO: i32 = 42;
450 Some(x) if x == FORTY_TWO => ...
457 In Rust, you can only move a value when its size is known at compile time.
459 To work around this restriction, consider "hiding" the value behind a reference:
460 either `&x` or `&mut x`. Since a reference has a fixed size, this lets you move
465 An if-let pattern attempts to match the pattern, and enters the body if the
466 match was successful. If the match is irrefutable (when it cannot fail to
467 match), use a regular `let`-binding instead. For instance:
470 struct Irrefutable(i32);
471 let irr = Irrefutable(0);
473 // This fails to compile because the match is irrefutable.
474 if let Irrefutable(x) = irr {
475 // This body will always be executed.
480 let Irrefutable(x) = irr;
486 A while-let pattern attempts to match the pattern, and enters the body if the
487 match was successful. If the match is irrefutable (when it cannot fail to
488 match), use a regular `let`-binding inside a `loop` instead. For instance:
491 struct Irrefutable(i32);
492 let irr = Irrefutable(0);
494 // This fails to compile because the match is irrefutable.
495 while let Irrefutable(x) = irr {
501 let Irrefutable(x) = irr;
508 Enum variants are qualified by default. For example, given this type:
517 you would match it using:
526 If you don't qualify the names, the code will bind new variables named "GET" and
527 "POST" instead. This behavior is likely not what you want, so `rustc` warns when
530 Qualified names are good practice, and most code works well with them. But if
531 you prefer them unqualified, you can import the variants into scope:
535 enum Method { GET, POST }
540 When using a lifetime like `'a` in a type, it must be declared before being
543 These two examples illustrate the problem:
546 // error, use of undeclared lifetime name `'a`
547 fn foo(x: &'a str) { }
550 // error, use of undeclared lifetime name `'a`
555 These can be fixed by declaring lifetime parameters:
558 fn foo<'a>(x: &'a str) { }
567 Declaring certain lifetime names in parameters is disallowed. For example,
568 because the `'static` lifetime is a special built-in lifetime name denoting
569 the lifetime of the entire program, this is an error:
572 // error, illegal lifetime parameter name `'static`
573 fn foo<'static>(x: &'static str) { }
578 A lifetime name cannot be declared more than once in the same scope. For
582 // error, lifetime name `'a` declared twice in the same scope
583 fn foo<'a, 'b, 'a>(x: &'a str, y: &'b str) { }
588 This error indicates that a static or constant references itself.
589 All statics and constants need to resolve to a value in an acyclic manner.
591 For example, neither of the following can be sensibly compiled:
604 This error indicates the use of a loop keyword (`break` or `continue`) inside a
605 closure but outside of any loop. Erroneous code example:
608 let w = || { break; }; // error: `break` inside of a closure
611 `break` and `continue` keywords can be used as normal inside closures as long as
612 they are also contained within a loop. To halt the execution of a closure you
613 should instead use a return statement. Example:
627 This error indicates the use of a loop keyword (`break` or `continue`) outside
628 of a loop. Without a loop to break out of or continue in, no sensible action can
629 be taken. Erroneous code example:
633 break; // error: `break` outside of loop
637 Please verify that you are using `break` and `continue` only in loops. Example:
649 This is because of a type mismatch between the associated type of some
650 trait (e.g. `T::Bar`, where `T` implements `trait Quux { type Bar; }`)
651 and another type `U` that is required to be equal to `T::Bar`, but is not.
654 Here is a basic example:
657 trait Trait { type AssociatedType; }
658 fn foo<T>(t: T) where T: Trait<AssociatedType=u32> {
661 impl Trait for i8 { type AssociatedType = &'static str; }
665 Here is that same example again, with some explanatory comments:
668 trait Trait { type AssociatedType; }
670 fn foo<T>(t: T) where T: Trait<AssociatedType=u32> {
671 // ~~~~~~~~ ~~~~~~~~~~~~~~~~~~
673 // This says `foo` can |
674 // only be used with |
676 // implements `Trait`. |
678 // This says not only must
679 // `T` be an impl of `Trait`
680 // but also that the impl
681 // must assign the type `u32`
682 // to the associated type.
686 impl Trait for i8 { type AssociatedType = &'static str; }
687 ~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
692 // ... but it is an implementation
693 // that assigns `&'static str` to
694 // the associated type.
697 // Here, we invoke `foo` with an `i8`, which does not satisfy
698 // the constraint `<i8 as Trait>::AssociatedType=u32`, and
699 // therefore the type-checker complains with this error code.
702 Here is a more subtle instance of the same problem, that can
703 arise with for-loops in Rust:
706 let vs: Vec<i32> = vec![1, 2, 3, 4];
715 The above fails because of an analogous type mismatch,
716 though may be harder to see. Again, here are some
717 explanatory comments for the same example:
721 let vs = vec![1, 2, 3, 4];
723 // `for`-loops use a protocol based on the `Iterator`
724 // trait. Each item yielded in a `for` loop has the
725 // type `Iterator::Item` -- that is,I `Item` is the
726 // associated type of the concrete iterator impl.
730 // | We borrow `vs`, iterating over a sequence of
731 // | *references* of type `&Elem` (where `Elem` is
732 // | vector's element type). Thus, the associated
733 // | type `Item` must be a reference `&`-type ...
735 // ... and `v` has the type `Iterator::Item`, as dictated by
736 // the `for`-loop protocol ...
742 // ... but *here*, `v` is forced to have some integral type;
743 // only types like `u8`,`i8`,`u16`,`i16`, et cetera can
744 // match the pattern `1` ...
749 // ... therefore, the compiler complains, because it sees
750 // an attempt to solve the equations
751 // `some integral-type` = type-of-`v`
752 // = `Iterator::Item`
753 // = `&Elem` (i.e. `some reference type`)
755 // which cannot possibly all be true.
761 To avoid those issues, you have to make the types match correctly.
762 So we can fix the previous examples like this:
766 trait Trait { type AssociatedType; }
767 fn foo<T>(t: T) where T: Trait<AssociatedType = &'static str> {
770 impl Trait for i8 { type AssociatedType = &'static str; }
774 let vs = vec![1, 2, 3, 4];
785 You tried to use a type which doesn't implement some trait in a place which
786 expected that trait. Erroneous code example:
789 // here we declare the Foo trait with a bar method
794 // we now declare a function which takes an object implementing the Foo trait
795 fn some_func<T: Foo>(foo: T) {
800 // we now call the method with the i32 type, which doesn't implement
802 some_func(5i32); // error: the trait `Foo` is not implemented for the
807 In order to fix this error, verify that the type you're using does implement
815 fn some_func<T: Foo>(foo: T) {
816 foo.bar(); // we can now use this method since i32 implements the
820 // we implement the trait on the i32 type
826 some_func(5i32); // ok!
832 This error indicates that type inference did not result in one unique possible
833 type, and extra information is required. In most cases this can be provided
834 by adding a type annotation. Sometimes you need to specify a generic type
837 A common example is the `collect` method on `Iterator`. It has a generic type
838 parameter with a `FromIterator` bound, which for a `char` iterator is
839 implemented by `Vec` and `String` among others. Consider the following snippet
840 that reverses the characters of a string:
843 let x = "hello".chars().rev().collect();
846 In this case, the compiler cannot infer what the type of `x` should be:
847 `Vec<char>` and `String` are both suitable candidates. To specify which type to
848 use, you can use a type annotation on `x`:
851 let x: Vec<char> = "hello".chars().rev().collect();
854 It is not necessary to annotate the full type. Once the ambiguity is resolved,
855 the compiler can infer the rest:
858 let x: Vec<_> = "hello".chars().rev().collect();
861 Another way to provide the compiler with enough information, is to specify the
862 generic type parameter:
865 let x = "hello".chars().rev().collect::<Vec<char>>();
868 Again, you need not specify the full type if the compiler can infer it:
871 let x = "hello".chars().rev().collect::<Vec<_>>();
874 Apart from a method or function with a generic type parameter, this error can
875 occur when a type parameter of a struct or trait cannot be inferred. In that
876 case it is not always possible to use a type annotation, because all candidates
877 have the same return type. For instance:
881 // Some fields omitted.
890 let number = Foo::bar();
895 This will fail because the compiler does not know which instance of `Foo` to
896 call `bar` on. Change `Foo::bar()` to `Foo::<T>::bar()` to resolve the error.
900 This error indicates that the given recursion limit could not be parsed. Ensure
901 that the value provided is a positive integer between quotes, like so:
904 #![recursion_limit="1000"]
909 Patterns used to bind names must be irrefutable. That is, they must guarantee
910 that a name will be extracted in all cases. Instead of pattern matching the
911 loop variable, consider using a `match` or `if let` inside the loop body. For
915 // This fails because `None` is not covered.
920 // Match inside the loop instead:
930 if let Some(x) = item {
938 Mutable borrows are not allowed in pattern guards, because matching cannot have
939 side effects. Side effects could alter the matched object or the environment
940 on which the match depends in such a way, that the match would not be
941 exhaustive. For instance, the following would not match any arm if mutable
942 borrows were allowed:
947 option if option.take().is_none() => { /* impossible, option is `Some` */ },
948 Some(_) => { } // When the previous match failed, the option became `None`.
954 Assignments are not allowed in pattern guards, because matching cannot have
955 side effects. Side effects could alter the matched object or the environment
956 on which the match depends in such a way, that the match would not be
957 exhaustive. For instance, the following would not match any arm if assignments
963 option if { option = None; false } { },
964 Some(_) => { } // When the previous match failed, the option became `None`.
970 In certain cases it is possible for sub-bindings to violate memory safety.
971 Updates to the borrow checker in a future version of Rust may remove this
972 restriction, but for now patterns must be rewritten without sub-bindings.
976 match Some("hi".to_string()) {
977 ref op_string_ref @ Some(ref s) => ...
982 match Some("hi".to_string()) {
984 let op_string_ref = &Some(s);
991 The `op_string_ref` binding has type `&Option<&String>` in both cases.
993 See also https://github.com/rust-lang/rust/issues/14587
997 In an array literal `[x; N]`, `N` is the number of elements in the array. This
998 number cannot be negative.
1002 The length of an array is part of its type. For this reason, this length must be
1003 a compile-time constant.
1007 This error occurs when the compiler was unable to infer the concrete type of a
1008 variable. It can occur for several cases, the most common of which is a
1009 mismatch in the expected type that the compiler inferred for a variable's
1010 initializing expression, and the actual type explicitly assigned to the
1016 let x: i32 = "I am not a number!";
1017 // ~~~ ~~~~~~~~~~~~~~~~~~~~
1019 // | initializing expression;
1020 // | compiler infers type `&str`
1022 // type `i32` assigned to variable `x`
1027 Types in type definitions have lifetimes associated with them that represent
1028 how long the data stored within them is guaranteed to be live. This lifetime
1029 must be as long as the data needs to be alive, and missing the constraint that
1030 denotes this will cause this error.
1033 // This won't compile because T is not constrained, meaning the data
1034 // stored in it is not guaranteed to last as long as the reference
1039 // This will compile, because it has the constraint on the type parameter
1040 struct Foo<'a, T: 'a> {
1047 Types in type definitions have lifetimes associated with them that represent
1048 how long the data stored within them is guaranteed to be live. This lifetime
1049 must be as long as the data needs to be alive, and missing the constraint that
1050 denotes this will cause this error.
1053 // This won't compile because T is not constrained to the static lifetime
1054 // the reference needs
1059 // This will compile, because it has the constraint on the type parameter
1060 struct Foo<T: 'static> {
1067 Method calls that aren't calls to inherent `const` methods are disallowed
1068 in statics, constants, and constant functions.
1073 const BAZ: i32 = Foo(25).bar(); // error, `bar` isn't `const`
1078 const fn foo(&self) -> i32 {
1079 self.bar() // error, `bar` isn't `const`
1082 fn bar(&self) -> i32 { self.0 }
1086 For more information about `const fn`'s, see [RFC 911].
1088 [RFC 911]: https://github.com/rust-lang/rfcs/blob/master/text/0911-const-fn.md
1094 > It is illegal for a static to reference another static by value. It is
1095 > required that all references be borrowed.
1097 [RFC 246]: https://github.com/rust-lang/rfcs/pull/246
1101 The value assigned to a constant expression must be known at compile time,
1102 which is not the case when comparing raw pointers. Erroneous code example:
1105 static foo: i32 = 42;
1106 static bar: i32 = 43;
1108 static baz: bool = { (&foo as *const i32) == (&bar as *const i32) };
1109 // error: raw pointers cannot be compared in statics!
1112 Please check that the result of the comparison can be determined at compile time
1113 or isn't assigned to a constant expression. Example:
1116 static foo: i32 = 42;
1117 static bar: i32 = 43;
1119 let baz: bool = { (&foo as *const i32) == (&bar as *const i32) };
1120 // baz isn't a constant expression so it's ok
1125 The value assigned to a constant expression must be known at compile time,
1126 which is not the case when dereferencing raw pointers. Erroneous code
1130 const foo: i32 = 42;
1131 const baz: *const i32 = (&foo as *const i32);
1133 const deref: i32 = *baz;
1134 // error: raw pointers cannot be dereferenced in constants
1137 To fix this error, please do not assign this value to a constant expression.
1141 const foo: i32 = 42;
1142 const baz: *const i32 = (&foo as *const i32);
1144 unsafe { let deref: i32 = *baz; }
1145 // baz isn't a constant expression so it's ok
1148 You'll also note that this assignment must be done in an unsafe block!
1152 It is not allowed for a mutable static to allocate or have destructors. For
1156 // error: mutable statics are not allowed to have boxes
1157 static mut FOO: Option<Box<usize>> = None;
1159 // error: mutable statics are not allowed to have destructors
1160 static mut BAR: Option<Vec<i32>> = None;
1165 In Rust 1.3, the default object lifetime bounds are expected to
1166 change, as described in RFC #1156 [1]. You are getting a warning
1167 because the compiler thinks it is possible that this change will cause
1168 a compilation error in your code. It is possible, though unlikely,
1169 that this is a false alarm.
1171 The heart of the change is that where `&'a Box<SomeTrait>` used to
1172 default to `&'a Box<SomeTrait+'a>`, it now defaults to `&'a
1173 Box<SomeTrait+'static>` (here, `SomeTrait` is the name of some trait
1174 type). Note that the only types which are affected are references to
1175 boxes, like `&Box<SomeTrait>` or `&[Box<SomeTrait>]`. More common
1176 types like `&SomeTrait` or `Box<SomeTrait>` are unaffected.
1178 To silence this warning, edit your code to use an explicit bound.
1179 Most of the time, this means that you will want to change the
1180 signature of a function that you are calling. For example, if
1181 the error is reported on a call like `foo(x)`, and `foo` is
1185 fn foo(arg: &Box<SomeTrait>) { ... }
1188 you might change it to:
1191 fn foo<'a>(arg: &Box<SomeTrait+'a>) { ... }
1194 This explicitly states that you expect the trait object `SomeTrait` to
1195 contain references (with a maximum lifetime of `'a`).
1197 [1]: https://github.com/rust-lang/rfcs/pull/1156
1203 register_diagnostics! {
1212 E0264, // unknown external lang item
1213 E0269, // not all control paths return a value
1214 E0270, // computation may converge in a function marked as diverging
1215 E0272, // rustc_on_unimplemented attribute refers to non-existent type parameter
1216 E0273, // rustc_on_unimplemented must have named format arguments
1217 E0274, // rustc_on_unimplemented must have a value
1218 E0275, // overflow evaluating requirement
1219 E0276, // requirement appears on impl method but not on corresponding trait method
1220 E0278, // requirement is not satisfied
1221 E0279, // requirement is not satisfied
1222 E0280, // requirement is not satisfied
1223 E0281, // type implements trait but other trait is required
1224 E0283, // cannot resolve type
1225 E0284, // cannot resolve type
1226 E0285, // overflow evaluation builtin bounds
1227 E0298, // mismatched types between arms
1228 E0299, // mismatched types between arms
1229 E0300, // unexpanded macro
1230 E0304, // expected signed integer constant
1231 E0305, // expected constant
1232 E0311, // thing may not live long enough
1233 E0312, // lifetime of reference outlives lifetime of borrowed content
1234 E0313, // lifetime of borrowed pointer outlives lifetime of captured variable
1235 E0314, // closure outlives stack frame
1236 E0315, // cannot invoke closure outside of its lifetime
1237 E0316, // nested quantification of lifetimes
1238 E0370, // discriminant overflow
1239 E0400 // overloaded derefs are not allowed in constants