As described here:
https://devblogs.microsoft.com/oldnewthing/20150220-00/?p=44623
In order to allow Lambdas to be used with traditional Win32 APIs, they
emit a conversion function for (what Raymond Chen claims is all) a
number of the calling conventions. Through experimentation, we
discovered that the list isn't quite 'all'.
This patch implements this by taking the list of conversions that MSVC
emits (across 'all' architectures, I don't see any CCs on ARM), then
emits them if they are supported by the current target.
However, we also add 3 other options (which may be duplicates):
free-function, member-function, and operator() calling conventions. We
do this because we have an extension where we generate both free and
member for these cases so th at people specifying a calling convention
on the lambda will have the expected behavior when specifying one of
those two.
MSVC doesn't seem to permit specifying calling-convention on lambdas,
but we do, so we need to make sure those are emitted as well. We do this
so that clang-only conventions are supported if the user specifies them.
Should we call out that one of the existing member functions is likely to be thiscall which means we'll generate a version of the operator for that calling convention even though MSVC doesn't, but we want to do this because users can explicitly write the CC on the lambda (unlike in MSVC)? (I'm worried that lack of mention about thiscall may look like a bug to someone a few years down the line.)