This is a silly "extended" verification check that we only exercise
in test/Generics/validate_stdlib_generic_signatures.swift.
We were taking a requirement containing unbound dependent member types
and applying a substitution map to it, which would result in an
ErrorType, so the requirement was always considered unsatisfied here
and the check was not as useful as it should have been.
Instead, re-implement a version of isRequirementSatisfied() that only
uses generic signature queries instead of substitution here.
In this mode all C++ types are imported as unsafe by default. Users
explicitly marking types are escapable or not escapable can make them
imported as safe. In the future, we also want to import unannotated
functions as unsafe and add more logic to infer types that are actually
safe, like agregates of escapable types.
ModuleDecl kept track of all of the source files in the module so that it
could find the source file containing a given location, which relied on
a sorted array all of these source files. SourceManager has its own
similar data structure for a similar query mapping the locations to
buffer IDs.
Replace ModuleDecl's dats structure with a use of the SourceManager's version
with the mapping from buffer IDs to source files.
When we print types in the AST printer if for some reason we cannot find the
appropriate type to print or if the user explicitly asks, we fall back and use a
type repr instead.
This behavior causes a problem due to the implementation of sending results
using a sending type repr to communicate that the relevant function has a
sending result, but we actually do not use the sending type repr from that point
on. So as a result, in this fallback case, we put in one too many sending on the
result.
rdar://135594964
Now that every source file has a buffer ID, introduce the reverse mapping
so clients can find the source file(s) in their module that reference
that buffer ID.
We're using a small custom frontend tool to generate indexstore data for `.swiftinterface` files in the SDKs. We do this by treating the `.swiftinterface` file as the input of an interface compilation, but this exits early because it treats it as a `SourceFile` instead of an external `LoadedFile`. This happens even if we call `setIsSystemModule(true)` unless we skip setting the SDK path, but that causes other problems. It seems harmless to check for `SourceFile`s as well, so that a tool processing an SDK interface as a direct input still gets the right state.
The "buffer ID" in a SourceFile, which is used to find the source file's
contents in the SourceManager, has always been optional. However, the
effectively every SourceFile actually does have a buffer ID, and the
vast majority of accesses to this information dereference the optional
without checking.
Update the handful of call sites that provided `nullopt` as the buffer
ID to provide a proper buffer instead. These were mostly unit tests
and testing programs, with a few places that passed a never-empty
optional through to the SourceFile constructor.
Then, remove optionality from the representation and accessors. It is
now the case that every SourceFile has a buffer ID, simplying a bunch
of code.
The generality of the `AvailabilityContext` name made it seem like it
encapsulates more than it does. Really it just augments `VersionRange` with
additional set algebra operations that are useful for availability
computations. The `AvailabilityContext` name should be reserved for something
pulls together more than just a single version.
We don't really want to support this, at least not yet, but there
are ways to sneak it past the diagnostic that are hard to close.
Fixes rdar://problem/135348472.
