The recent Clang compiler change makes `-fno-modulemap-allow-subdirectory-search` the default behavior. This means that projects that use C++ interop and `#include <swift/bridging>` no longer compile, since Clang won't search for the SwiftBridging module under `usr/include/swift` anymore.
This change adds a new modulemap file to be installed at `toolchain/usr/include/module.modulemap`. This modulemap is under a default Clang include search path, which will make sure Clang can discover the SwiftBridging module.
rdar://123334601
This makes sure we are printing more than one level of C++ template specializations when emitting a Swift struct name.
For instance, `std::__wrap_iter<char*>` and `std::__wrap_iter<const char*>` are currently imported with the same name in Swift. This means the mangled string will be the same for these specializations, despite them being distinct types. This causes mangling errors.
rdar://117485399
My recent change started linking ClangImporter with Sema, which accidentally introduced a circular dependency between the two.
This patch avoid the usage of type checker logic from ClangImporter's automatic protocol conformance logic.
rdar://101763817
To determine whether to conform a C++ type to `CxxSequence` protocol automatically, ClangImporter checks if the corresponding iterator type conforms to `UnsafeCxxInputIterator`.
This logic had false-positives, e.g. `Optional<OpaquePointer>` was treated as if it conforms to `UnsafeCxxInputIterator` while it actually doesn't. This happened because `lookupConformance` returned a conformance with a conditional requirement (`Wrapped : UnsafeCxxInputIterator`) that is not satisfied for `OpaquePointer`.
rdar://100265664
This teaches ClangImporter to synthesize conformances of C++ iterator types to `UnsafeCxxInputIterator` protocol from the `Cxx` module.
We consider a C++ type to be an iterator if it defines a subtype (usually a typedef or a using decl) called `iterator_category` that inherits from `std::input_iterator_tag`.
rdar://96235368
This logic is going to be extended to inject the modulemap and the header of Glibc in addition to libstdc++. It doesn't depend on the rest of ClangImporter, so let's extract it to a separate file to make incremental builds and IDE features faster.
`ImportDecl.cpp` contained 10k+ lines of code, which caused slowdowns in incremental compilation and while editing the code in the IDE.
This change extracts a chunk of largely self-contained decl synthesis logic into a separate file.
Otherwise we set it on all targets/languages in a subdirectory (I forgot if it
propagates up). Regardless, this type of viral stuff is something we want to
move away from since it creates a code that is a "forall" piece of code rather
than a piece of code that only effects a single target.
I also conditionalized the actual definitions being added on the compiled file's
language being C,CXX,OBJC,OBJCXX since as we add Swift sources to the host side
of the compiler, we will not want these flags to propagate to Swift sources.
Implement a new "fast" dependency scanning option,
`-scan-dependencies`, in the Swift frontend that determines all
of the source file and module dependencies for a given set of
Swift sources. It covers four forms of modules:
1) Swift (serialized) module files, by reading the module header
2) Swift interface files, by parsing the source code to find imports
3) Swift source modules, by parsing the source code to find imports
4) Clang modules, using Clang's fast dependency scanning tool
A single `-scan-dependencies` operation maps out the full
dependency graph for the given Swift source files, including all
of the Swift and Clang modules that may need to be built, such
that all of the work can be scheduled up front by the Swift
driver or any other build system that understands this
option. The dependency graph is emitted as JSON, which can be
consumed by these other tools.
As part of this, we have to change the type export rules to
prevent `@convention(c)` function types from being used in
exported interfaces if they aren't serializable. This is a
more conservative version of the original rule I had, which
was to import such function-pointer types as opaque pointers.
That rule would've completely prevented importing function-pointer
types defined in bridging headers and so simply doesn't work,
so we're left trying to catch the unsupportable cases
retroactively. This has the unfortunate consequence that we
can't necessarily serialize the internal state of the compiler,
but that was already true due to normal type uses of aggregate
types from bridging headers; if we can teach the compiler to
reliably serialize such types, we should be able to use the
same mechanisms for function types.
This PR doesn't flip the switch to use Clang function types
by default, so many of the clang-function-type-serialization
FIXMEs are still in place.
Emitting Swift diagnostics in Clang buffers requires making those
buffers valid places to put Swift SourceLocs, which means making a
mirror of those buffers in the Swift SourceManager. This isn't a copy;
instead, any Clang SourceManagers that are involved are kept alive
until the importer is torn down. (There might be more than one because
of diagnostics emitted during module building.)
For a long time we only emitted diagnostics in Clang buffers if the
diagnostics came from Clang, but then we added another case for custom
Swift names that fail to import. I'm about to add another such
diagnostic, so let's formalize this buffer mapping first.
No intended functionality change.
This refactors DWARFImporter to become a part of ClangImporter, since
it needs access to many of its implementation details anyway. The
DWARFImporterDelegate is just another mechanism for deserializing
Clang ASTs and once we have a Clang AST, the processing is effectively
the same.
This is a follow up to the discussion on #22740 to switch the host
libraries to use the `target_link_libraries` rather than the
`LINK_LIBRARIES` special handling. This allows the dependency to be
properly tracked by CMake and allows us to use the more modern syntax.
This reverts commit 121f5b64be.
Sorry to revert this again. This commit makes some pretty big changes. After
messing with the merge-conflict created by this internally, I did not feel
comfortable landing this now. I talked with Saleem and he agreed with me that
this was the right thing to do.
The key thing here is that all of the underlying code is exactly the same. I
purposely did not debride anything. This is to ensure that I am not touching too
much and increasing the probability of weird errors from occurring. Thus the
exact same code should be executed... just the routing changed.
* Generate libSyntax API
This patch removes the hand-rolled libSyntax API and replaces it with an
API that's entirely automatically generated. This means the API is
guaranteed to be internally stylistically and functionally consistent.
These changes caused a number of issues:
1. No debug info is emitted when a release-debug info compiler is built.
2. OS X deployment target specification is broken.
3. Swift options were broken without any attempt any recreating that
functionality. The specific option in question is --force-optimized-typechecker.
Such refactorings should be done in a fashion that does not break existing
users and use cases.
This reverts commit e6ce2ff388.
This reverts commit e8645f3750.
This reverts commit 89b038ea7e.
This reverts commit 497cac64d9.
This reverts commit 953ad094da.
This reverts commit e096d1c033.
rdar://30549345
This patch splits add_swift_library into two functions one which handles
the simple case of adding a library that is part of the compiler being
built and the second handling the more complicated case of "target"
libraries, which may need to build for one or more targets.
The new add_swift_library is built using llvm_add_library, which re-uses
LLVM's CMake modules. In adapting to use LLVM's modules some of
add_swift_library's named parameters have been removed and
LINK_LIBRARIES has changed to LINK_LIBS, and LLVM_LINK_COMPONENTS
changed to LINK_COMPONENTS.
This patch also cleans up libswiftBasic's handling of UUID library and
headers, and how it interfaces with gyb sources.
add_swift_library also no longer has the FILE_DEPENDS parameter, which
doesn't matter because llvm_add_library's DEPENDS parameter has the same
behavior.
* [CMake] swiftClangImporter should depend on CLANG_TABLEGEN_TARGETS
Since the swiftClangImporter library uses generated headers from the clang tablegen targets it should have an explicit dependency. This fixes a dependency issue building swift in-tree with LLVM & Clang, and will not impact build-script builds because CLANG_TABLEGEN_TARGETS will be empty.
* [CMake] Add a comment explaining CLANG_TABLEGEN_TARGETS
The comment explains why this block doesn't need to be wrapped for non-standalone builds.
Introduces new files ClangAdapter.h/cpp, which will serve as a
convenient place to put code reasoning about Clang details. Refactors
out most Clang-related is*, has*, and get* methods from the
ImporterImpl. In the future, an adapter class could help serve to
seperate the concerns of the importer from the details of how to
correctly use Clang APIs.
Refactors much of the import name determination from ClangImporter.cpp
into ImportName.cpp.
This is not a perfect separation, but it's a step in the right
direction. Long term, we'd like to get as much functionality off of
the ClangImporter::Implementation class and onto more specialized and
seperable (and stateless!) components.
Setting this value is equivalent to setting:
include_directories(${CMAKE_CURRENT_BINARY_DIR} ${CMAKE_CURRENT_SOURCE_DIR})
in all subdirectories. Since these are all macros, this means that we are adding to the configuration
path the root swift directory. There is no reason to do this and will result in
confusion/bugs in the future.
rdar://26154980
As a first step to allowing the build script to build *only*
static library versions of the stdlib, change `add_swift_library`
such that callers must pass in `SHARED`, `STATIC`, or `OBJECT_LIBRARY`.
Ideally, only these flags would be used to determine whether to
build shared, static, or object libraries, but that is not currently
the case -- `add_swift_library` also checks whether the library
`IS_STDLIB` before performing certain additional actions. This will be
cleaned up in a future commit.
Moves CFPointeeInfo into CFTypeInfo.h/cpp, so that other parts of the
importer can re-use the logic for reasoning about CF types. This will
be needed by the import as member inference system to reason about
effective Clang contexts.
Introduces import-as-member (IAM) inferene system, to automatically
infer details that would otherwise have to be manually specified with
the swift_name attribute.
Basic functionality present, though there are some issues with
properties at the moment. No hooks, options, or tests yet, stay tuned.
Introduces new class, EnumInfo, just for the implementation of the
ClangImporter to encapsulate various computed information about the
enum we're importing.
This helps refactor some functionality, aids clarity, and also
prevents us from repeating calculations multiple times, as we were
doing with classifyEnum's macro-expansion tracking. Provides a base
where we can add more heavy lifting in classifyEnum in the future.
When we parse a bridging header, start building a mapping from Swift
names (both base names and full names) to the Clang declarations that
have those names in particular Clang contexts. For now, just provide
the ability to build the table (barely) and dump it out; we'll grow
it's contents in time.
