Adding non_exhaustive should disable missing_copy_implementations

[milliams]

I have the following minimal example:

#![deny(missing_copy_implementations)]

#[derive(Clone)]
pub enum MyEnum {
    A,
}

It does as I expect and gives the error:

error: type could implement `Copy`; consider adding `impl Copy`
 --> src/lib.rs:4:1
  |
4 | / pub enum MyEnum {
5 | |     A,
6 | | }
  | |_^
  |
note: the lint level is defined here
 --> src/lib.rs:1:9
  |
1 | #![deny(missing_copy_implementations)]
  |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

However, since this enum is going to have more options added to it in the future, for example, B(String), I go ahead and label it as non_exhaustive:

#![deny(missing_copy_implementations)]

#[derive(Clone)]
#[non_exhaustive]
pub enum MyEnum {
    A,
}

I would expect that this would disable the missing_copy_implementations lint in this case. This is because, otherwise adding a Copy implementation, e.g.:

#![deny(missing_copy_implementations)]

#[derive(Clone, Copy)]
#[non_exhaustive]
pub enum MyEnum {
    A,
}

would then break when, in the future, I add my B variant:

#![deny(missing_copy_implementations)]

#[derive(Clone, Copy)]
#[non_exhaustive]
pub enum MyEnum {
    A,
    B(String),
}

with:

error[E0204]: the trait `Copy` cannot be implemented for this type
 --> src/lib.rs:3:17
  |
3 | #[derive(Clone, Copy)]
  |                 ^^^^
...
7 |     B(String),
  |       ------ this field does not implement `Copy`
  |

In short, I would expect that adding non_exhaustive would disable the missing_copy_implementations lint as it's not future-proof, and the whole point of the non_exhaustive attribute is to say "that a type or variant may have more fields or variants added in the future".

[rmehri01]

@rustbot claim