`get_async_continuation[_addr]` begins a suspend operation by accessing the continuation value that can resume
the task, which can then be used in a callback or event handler before executing `await_async_continuation` to
suspend the task.
checks to check for type context instead of local context.
This generalization will help us implement property wrappers on
global variables, which should use the same approach of not adding
synthesized accessors to the AST and instead lazily visit them in
SILGen.
A type is IsTypeExpansionSensitive if it contains an opaque result type that influences how the type is lowered.
This could be because the type mentions an opaque archetype and
therefore we would look through to the underlying type depending on the
type expansion and could get a different SIL type. For example
'() -> out some P' could lower to '() -> @out Int'.
Or this could be because when we lower an aggregate type some of its
fields are opaque types that could be looked through and therefore the
aggregate has different lowering (e.g address vs. loadable) in different
type expansion contexts.
By replacing it this change also fixes an infinite recursion in
hasOpaqueArchetypePropertiesOrCases.
rdar://68798822
I don't have a test case for this bug based on the current code. But
the fix is clearly needed to have a unique AccessStorage object for
each property. The AccessPath commits will contain test cases for this
functionality.
This patch includes a large number of changes to make sure that:
1. When ExtInfo values are created, we store a ClangTypeInfo if applicable.
2. We reduce dependence on storing SIL representations in ASTExtInfo values.
3. Reduce places where we sloppily create ASTExtInfo values which should
store a Clang type but don't. In certain places, this is unavoidable;
see [NOTE: ExtInfo-Clang-type-invariant].
Ideally, we would check that the appropriate SILExtInfo does always store
a ClangTypeInfo. However, the presence of the HasClangFunctionTypes option
means that we would need to condition that assertion based on a dynamic check.
Plumbing the setting down to SILExtInfoBuilder's checkInvariants would be too
much work. So we weaken the check for now; we should strengthen it once we
"turn on" HasClangFunctionTypes and remove the dynamic feature switch.
The leak happened in this scenario:
1. A function becomes dead and gets deleted (which means: it gets added to the zombie-list)
2. A function with the same name is created again. This can happen with specializations.
In such a case we just removed the zombie function from the zombie-list without deleting it.
But we cannot delete zombie functions, because they might still be referenced by metadata, like debug-info.
Therefore the right fix is to resurrect the zombie function if a new function is created with the same name.
rdar://problem/66931238
Expand to other cases where we emit a
native-to-foreign thunk, but didn't previously
return true. Because this now includes @objc
entry-points for methods, adjust the linking logic
so it can maintain more restrictive linkages for
things like private decls.
At all call-sites, the extInfo passed as the third argument is computed directly
from the second argument, so we compute it directly in getBridgedFunctionType.
