rustc build warning: diagnostic code E0045 already used

[thepowersgang]

When building current rust master, the following warning is emitted (non-fatal)

rustc: x86_64-unknown-linux-gnu/stage0/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_typeck
../src/librustc_typeck/astconv.rs:1565:17: 1566:79 warning: diagnostic code E0045 already used
../src/librustc_typeck/astconv.rs:1565                 span_err!(tcx.sess, ast_ty.span, E0045,
../src/librustc_typeck/astconv.rs:1566                           "variadic function must have C calling convention");
../src/librustc_typeck/check/mod.rs:688:13: 701:14 note: previous invocation
../src/librustc_typeck/check/mod.rs:688             for item in &m.items {
../src/librustc_typeck/check/mod.rs:689                 let pty = ccx.tcx.lookup_item_type(local_def(item.id));
../src/librustc_typeck/check/mod.rs:690                 if !pty.generics.types.is_empty() {
../src/librustc_typeck/check/mod.rs:691                     span_err!(ccx.tcx.sess, item.span, E0044,
../src/librustc_typeck/check/mod.rs:692                         "foreign items may not have type parameters");
../src/librustc_typeck/check/mod.rs:693                 }

[thepowersgang]

A quick check of the repo using github's search shows that librustc_typeck/check/mod.rs L697 and src/librustc_typeck/astconv.rs L1565 both define E0045

[arielb1]

Can the code in check even be reached?

[pnkfelix]

How about we just factor out the common three-lines of the check into its own subroutine in the crate, to placate the duplicate-checker.

[RalfJung]

The warning message is particularly confusing, because the code snippet showing the "previous invocation" demonstrates a use of E0044, not E0045.

[michaelsproul]

Or, should we reconsider the concept of a duplicate-checker all together? Unifying errors for different code paths seems like it may be useful if the errors are manifestations of the same thing...

[michaelsproul]

On the other hand, maybe we should just factor it out for clarity.

[GuillaumeGomez]

I'll take a quick look into it. Maybe centralizing calls of errors might be good idea (I guess ?).

[pnkfelix]

Fixed by #27188