Store `@differentiable` attribute requirements as `GenericSignature` instead of `ArrayRef<Requirement>`s?

[dan-zheng]

@Slava_Pestov

It would help if you clarified what you're actually doing by remapping types. The two functions you mention are different -- mapTypeIntoContext() replaces generic parameters with the archetypes from the generic environment. If you're emitting a SIL function whose generic signature is the derived generic signature with the additonal requirements, you probably want to set the SILFunction's generic environment to be the derived generic environment, and use mapTypeIntoContext() to create types for use in SIL instructions in the body.

Yes, our use case is exactly "creating a SIL function with the derivative generic environment with additional requirements, and using the environment to remap types via TypeSubstCloner machinery".

@Slava_Pestov

A generic signature itself does not have archetypes associated with it -- that's why you can create zero or more generic environments from a generic signature. We plan on simplifying this at some point so that each signature has exactly one generic environment which is lazily built as needed. Once this is done you can think of the two concepts are mostly interchangeable.

Thanks for this clarification, I’ve been wondering about this distinction. Generic environments have archetypes while generic signatures do not (only generic type parameter types and requirements).

---

Tentatively, we’ll pursue storing a derivative GenericSignature in AST DifferentiableAttr and SILDifferentiableAttr then. Directly storing GenericSignature will reduce code duplication and fix issues where derivative generic signature is currently computed incorrectly. Derivative SIL functions will have an (optional) generic environment created from this GenericSignature, same as today.

Eventually, differentiability witness tables will replace SILDifferentiableAttr and store an optional derivative GenericSignature per entry.

Thanks again!