The existing code will use paths for "iphoneos" because the triples for
macCatalyst are in the form "<arch>-apple-iosXX.yy-macabi", which the
code interprets as an iPhone triple. This seems to work in Xcode because
the "iphoneos" folder is always there. When building in open source,
this seems to work because it is also normal to have the iPhone SDK
configured. This is not the case if you want to build the macOS SDK in
isolation.
The code changes detect the macCatalyst environment from the triple and
use the "macosx" paths instead, otherwise it follows the same code path
as before. This matches many places in the CMakeLists.txt files in which
macCatalyst support pieces are only enabled when the SDK is macOS.
The modified function is also used for the libc modulemap of non-Darwin
platforms, but for those triples, the macCatalyst environment should not
be detected, so the libc modulemap should not be affected by this
change.
This is a followup to #76260 and #74994.
For now, this logic is used for importing fewer unannotated types as
unsafe. In the future, this logic will be used by escapability inference
for other (non-aggregate) types.
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.
`swift-modulewrap` uses the `ClangImporter` to obtain a module loader,
but it doesn't take an SDK argument (nor does anything bother to pass
one), which means that when cross-compiling you get warnings about not
being able to find the C library.
Suppress the warning by telling the `ClangImporter` that we don't care
about the C library here.
rdar://115918181
The lifetimebound annotations are now imported as lifetime dependencies.
This works for basic cases but there are still some parts missing:
* Support lifeitmebound annotations on constructors
* A way to represent immortal/static lifetimes on the C++ side
When rendering a swift_attr attribute for parsing, we were creating both
the backing buffer and a source file, but not providing the buffer's ID
to the source file, so we couldn't find the source code again. Fix that.
While here, also register the source file with the module, so we can
find the source file again based on location.
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.
This service on ModuleDecl wasn't actually used before this PR. The main
client in ASTPrinter calls direclty the underlying logic in FileUnit.
Let's update it for our needs.
Use `-fsyntax-only` action to scan clang module dependencies instead of
`-c` option. This fixes a non-deterministic output on windows from
scan-dependency output because `-c` implies it needs a temporary object
file in the cc1 arguments that makes the pcm compilation command
different every run. This can also make the `-Xcc` commands for PCM
compilation simpler and more likely to be deduplicated by build system.
rdar://135319536
This change fixes a swift-ide-test crash that occured in the Interop\Cxx\stdlib\msvcprt-module-interface.swift testcase with a newer MSVC, as one of its operator() had a parameter with a type that couldn't have been imported. The change ensures that body params are not used if they're null.
Honour the SDK for APINotes to augment the system libraries. This allows
us to distribute APINotes with the Swift SDK and impact the system
without having to map the APINotes into the filesystem.
