[AutoDiff] TF-1046: put gen sig in more places

[marcrasi]

This PR puts the generic signature of the original function in the DifferentiableAttribute, solving TF-1046.

This exposed 3 latent bugs, which I had to deal with:

• getNextOverriddenVTableEntry was returning a result with the generic signature of the overriding derivative, but it should return a result with the generic signature of the overridden derivative.
• TF-1055. Dealt with by adding a special case. See TODO(TF-1055) in the code.
• [AutoDiff] forbid overly-constrained derivative requirement implementations #28716 is incorrect for conditional conformances because the conformance condition (which is part of the witness generic signature) is not satisfied by the requirement. This PR exposed the incorrectness and caused some tests to fail. I fixed it by expanding the check from [AutoDiff] forbid overly-constrained derivative requirement implementations #28716 to accept witness requirements that are satisfied by the conformance condition.

[dan-zheng]

Nice!

[dan-zheng]

I wonder what's the specific symptom of TF-1055?

Referencing the example:

sil_differentiability_witness @foo <T: A> { ... }

sil_differentiability_witness @foo <T: B> { ... }

sil @foo : <T> (T) -> T

sil @example
bb0:
  %1 = function_ref @foo : <T> (T) -> T
  %2 = differentiable_function %1
  %3 = differentiable_function_extract [vjp] %2
  ...

Currently, is the symptom that one differentiability witness is chosen at random during differentiable_function canonicalization?

[marcrasi]

You'd get an error that foo is not differentiable, even if the next instruction applies the vjp to something that conforms to A. However, I don't know if any swift code will actually generate SIL like that.

With this check here, I know of no swift code that causes any symptoms.

A symptom that you can get from real swift, if you remove the check here, is:

protocol P {
  @differentiable
  func f(_ x: Float) -> Float
}

extension P {
  @differentiable
  func f(_ x: Float) -> Float
}

struct S: P {}

=>

error: function is not differentiable because `Self: P` is not satisfied

(error from memory, don't have a compiler to test it on right now)

[marcrasi]

The reason that error happens is that the differentiability witness table for P.f has a Self: P constraint, and the substitution map that gets passed in to diagnoseUnsatisfiedRequirements doesn't have anything satisfying those constraints.

[dan-zheng]

I see, thanks for the details! I wonder if this is a deficiency in the code around diagnoseUnsatisfiedRequirements (e.g. logic for computing the substitution map). I'll try to reproduce the issue after this patch lands.

[marcrasi]

@swift-ci please test tensorflow

[marcrasi]

All downstream repo tests passed, except swift-jupyter flaked. I'm rerunning that to make sure it's not a real failure. If that passes, then I'll merge this!