If the concrete type is an existential or a generic type, we should not perform the optimization, because we don’t know enough information about it.
Fixes rdar://31372306
Till now createApply, createTryApply, createPartialApply were taking some arguments like SubstCalleeType or ResultType. But these arguments are redundant and can be easily derived from other arguments of these functions. There is no need to put the burden of their computation on the clients of these APIs.
The removal of these redundant parameters simplifies the APIs and reduces the possibility of providing mismatched types by clients, which often happened in the past.
Replace `NameOfType foo = dyn_cast<NameOfType>(bar)` with DRY version `auto foo = dyn_cast<NameOfType>(bar)`.
The DRY auto version is by far the dominant form already used in the repo, so this PR merely brings the exceptional cases (redundant repetition form) in line with the dominant form (auto form).
See the [C++ Core Guidelines](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#es11-use-auto-to-avoid-redundant-repetition-of-type-names) for a general discussion on why to use `auto` to avoid redundant repetition of type names.
This bug occurs in real projects, when type aliases are involved.
The test-case is a bit hard to provide. I’ll try to provide it later, if I managed to reduce the original project to a small test-case.
But the fix is very obvious.
Fixes rdar://31768258
- Introduced a new helper class FunctionSignaturePartialSpecializer which provides most of the functionality required for producing a specialized generic signature based on the provided substitutions or requirements. The class consists of many small functions, which should make it easier to understand the code.
- Added a full support for partial specialization of generic parameters with generic substitutions (use flag `-Xllvm -sil-partial-specialization-with-generic-substitutions` to enable it)
- Removed the simpler version of the partial specializer which could partially specialize only generic parameters with non-generic substitutions. It is not needed anymore, because we can handle any substations now when performing the partial specialization.
- The functionality used by the EagerSpecializer to implement the partial specializations required by @_specialize is expressed in terms of FunctionSignaturePartialSpecializer as well. The code implementing it is much smaller now.
Partial specialization of generic parameters with generic substitutions is fully functional, but it is disabled by default, because it needs some tweaks when it comes to compile times and size of produced code. These issues will be addressed in the subsequent commits.
There were two bugs:
- A proper GenericContextScope was not set for type lowering
- Interface types were not mapped to contextual types before using them in SIL instructions
In case of a full specialization, the specialized function does not have a generic signature. Therefore there is no need to build it.
This speeds up the compilation by avoiding doing a useless work.
remapRequirements() was doing a whole lot of substitution work by
itself that the GenericSignatureBuilder is already capable of
doing. Use the GSB's functionality instead.
Rather than true (an error occurred) or false (the constraint was
resolved), introduce ConstraintResult to better model what
happened. NFC for now, but the intent here is to report unresolved
constraints through this mechanism.
Properly cast the result of a devirtualized partial_apply, because this may be required in case of classes implementing protocols. More specifically, it came up when there is a derived class of a class implementing an initializer required by the protocol.
Fixes rdar://31459426 (SR-4501) and rdar://31479426 (SR-3476)
