Begin using `AvailabilityContext` as the availability representation in
`TypeRefinementContext`, instead of only storing platform introduction
availability ranges.
There should be no functional changes since this just changes the
representation of the existing information stored by `TypeRefinementContext`.
However, in the future `AvailabilityContext` will be expanded to represent
additional availability constraints.
This class is designed to be a compact representation of the active
availability constraints in a specific scope. For now, it only models platform
introduction availability but it will soon be updated to cover additional
availability constraints, like platform unavailability.
In anticipation of needing to reference `AvailabilityContext`s from
`TypeRefinementContext`s and increasing memory requirements for these contexts,
a cache of uniqued instances of `AvailabilityContext` are stored in a
`llvm::FoldingSet` on `ASTContext`.
This patch introduces handling of ObjC protocols similar to how ObjC
classes work. Since this only works in ObjC++, all declarations
containing ObjC protocols will be protected by the __OBJC__ macro.
This patch results in some `_bridgeObjC` methods being exposed, we might
end up hiding those in the future, but there is no harm having them in
the interop header for the interim period.
rdar://136757913
This adds a pair of Swift protocols that represents C++ iterator types conforming to `std::contiguous_iterator_tag` requirements. These are random access iterators that guarantee that the values are stored in consequent memory addresses.
This will be used to optimize usage of C++ containers such as `std::vector` from Swift, for instance, by providing an overload of `withContiguousStorageIfAvailable` for contiguous containers.
rdar://137877849
This field was complicating initialization of `TypeRefinementContext` and
bloating its storage just to make it slightly more convenient to look up
information that is pretty easy to derive on-demand when it is actually needed.
Instead of doing the pattern parsing in both the
C++ parser and ASTGen, factor out the parsing into
a request that returns the pattern to emit, regex
type, and version. This can then be lazily run
during type-checking.
Add a setting to IRGenOptions and key off of it to emit yield_once_2
coroutines using either (1) the same code-path as yield_once coroutines
or (2) a new, not-yet implemented code-path.
Add flags to set the value in both directions. During bringup, by
default, use the existing caller-allocated ABI.
Temporarily allow the legacy behavior of allowing caller coroutine
accessors to observe errors (i.e. by executing no code after the yield
if the caller threw an error) behind the
CoroutineAccessorsUnwindOnCallerError flag.
While returning the actual child vector from
`ExpandChildTypeRefinementContextsRequest` is a nice idea, it is both
inefficient (the vector gets copied in and out) and kind of inaccurate, since
the vector remains mutable after the initial expansion and may gain additional
children as macros are lazily expanded.
Also rename it to `getExplicitReturnStmts` for clarity and have it
take a `SmallVector` out parameter instead as a small optimization and
to discourage use of this new method as an alternative to
`AnyFunctionRef::bodyHasExplicitReturnStmt`.
