Closures appearing in freestanding macro arguments don't have
discriminators assigned, since we don't actually emit them.
Similarly we skip recording opaque return types that appear in macro
arguments, since they don't get emitted.
However this logic didn't take delayed parsing into account, which must
save and restore the InFreestandingMacroArgument bit correctly.
As a result, if the freestanding macro argument contained a closure
which contained a local function with a declaration that has an
opaque return type, we would crash in serialization from attempting
to mangle an opaque return type nested inside of a closure without a
discriminator.
Fixes rdar://135445004
With the `CoroutineAccessors` feature, `read` is allowed along with
`get` and `set`; alter the diagnostic that's issued when a disallowed
introducer is listed in the requirement list to indicate that `read` is
one of those which are valid, but only when the feature is enabled.
`Builtin.FixedArray<let N: Int, T: ~Copyable & ~Escapable>` has the layout of `N` elements of type `T` laid out
sequentially in memory (with the tail padding of every element occupied by the array). This provides a primitive
on which the standard library `Vector` type can be built.
Implement a query that returns the `AvailabilityContext` for a given
`SourceLoc` and `DeclContext`. Re-implement the existing type checker query
that just returns an `AvailabilityRange` on top of the new query.
Make the pointer to uniqued storage an implementation detail of an
`AvailabilityContext` value. This way clients of `AvailabilityContext` don't
need to think about pointers and can have access to mutating operations on a
context when appropriate.
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`.
When a type is explicitly annotated as escapable or non-escapable it has
requirements about the lifetime annotations. This patch introduces
diagnostics to detect that.
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
