Avoid deriving bounds from FnPtr

[sgasho]

closes: #143131
closes: #155446

We don't need bounds for the inputs and outputs of function pointers.

for the code below, for example,

#![allow(dead_code)]
trait SomeTrait {
    type SomeType<'a>;
}

#[derive(Clone)]
struct Foo<T: SomeTrait> {
    x: fn(T::SomeType<'_>)
}

fn main() {}

Before
An error occurs for a lifetime.

rustc +nightly -Zunpretty=expanded main.rs

error[E0637]: `'_` cannot be used here
 --> main.rs:8:23
  |
8 |     x: fn(T::SomeType<'_>),
  |                       ^^ `'_` is a reserved lifetime name

#![feature(prelude_import)]
#![no_std]
#![allow(dead_code)]
extern crate std;
#[prelude_import]
use ::std::prelude::rust_2015::*;
trait SomeTrait {
    type SomeType<'a>;
}

struct Foo<T: SomeTrait> {
    x: fn(T::SomeType<'_>),
}
#[automatically_derived]
impl<T: ::core::clone::Clone + SomeTrait> ::core::clone::Clone for Foo<T>
    where T::SomeType<'_>: ::core::clone::Clone {
    #[inline]
    fn clone(&self) -> Foo<T> {
        Foo { x: ::core::clone::Clone::clone(&self.x) }
    }
}

fn main() {}

After
where T::SomeType<'_>: ::core::clone::Clone, which was incorrect, and unnecessary, has gone
No errors.

rustc +issue143131 -Zunpretty=expanded main.rs

#![feature(prelude_import)]
#![no_std]
#![allow(dead_code)]
extern crate std;
#[prelude_import]
use ::std::prelude::rust_2015::*;
trait SomeTrait {
    type SomeType<'a>;
}

struct Foo<T: SomeTrait> {
    x: fn(T::SomeType<'_>),
}
#[automatically_derived]
impl<T: ::core::clone::Clone + SomeTrait> ::core::clone::Clone for Foo<T> {
    #[inline]
    fn clone(&self) -> Foo<T> {
        Foo { x: ::core::clone::Clone::clone(&self.x) }
    }
}

fn main() {}

[rustbot]

r? @chenyukang

rustbot has assigned @chenyukang.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler
• compiler expanded to 73 candidates
• Random selection from 20 candidates

[chenyukang]

according to the blame history, maybe r? @estebank need to confirm this change.

View changes since this review

[fmease]

Can this lead to pass→fail regressions? Does this need crater? Is T-compiler really the right team or is it T-libs{-api} or T-lang?

[sgasho]

Oh, I found a pass→fail case, but I think the new behavior is semantically correct.

code

trait SomeTrait {
    type SomeType<'a>;
}

#[derive(Clone)]
struct Concrete;

struct NotClone<'a>(&'a ());

impl SomeTrait for Concrete {
    type SomeType<'a> = NotClone<'a>;
}

#[derive(Clone)]
struct Foo<T: SomeTrait> {
    x: for<'a> fn(T::SomeType<'a>),
}

trait Local {}

impl<T: Clone> Local for T {}

// Before this PR: Foo<Concrete> does not satisfy Clone
// After this PR: it does -> impl conflicts

impl Local for Foo<Concrete> {}

fn main() {}

output

❯ rustc +issue143131 main.rs
error[E0119]: conflicting implementations of trait `Local` for type `Foo<Concrete>`
  --> main.rs:23:1
   |
21 | impl<T: Clone> Local for T {}
   | -------------------------- first implementation here
22 |
23 | impl Local for Foo<Concrete> {}
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ conflicting implementation for `Foo<Concrete>`

error: aborting due to 1 previous error

For more information about this error, try `rustc --explain E0119`.

This happens because the PR makes the derived Clone impl less constrained.
Some types that previously did not satisfy Clone can now satisfy it, which may expose coherence overlap with blanket impls.

The affected pattern seems quite narrow, but I agree that a crater run would be the safer way to measure the actual ecosystem impact.