This PR adds a variadic macro that builds a SwiftAttr string containing
the names of the template type parameters that need to be escapable for
the type to be considered escapable. It also adds logic to interpret
this annotation.
rdar://139065437
Occasionally, when the Swift compiler emits a diagnostic for a construct
that was imported from C++ we get a diagnostic with unknown location.
This is a bad user experience. It is particularly bad with the
borrow-checker related diagnostics. This patch extends the source
location importing to declarations in ClangImporter. There are some
invariants enforced by the Swift compile, e.g., a source range is
comprised of two valid source locations or two invalid ones. As a
result, this patch adds approximate source locations to some separators
like braces or parens that are not maintained by Clang. Having slightly
incorrect ranges in this case is better than emitting unknown source
locations.
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.
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.
This makes it easier to experiment with noescapable types in interop.
Moreover, we always wanted to have this annotation for completeness,
similar to SWIFT_NONCOPYABLE.
When caching is enabled with include-tree, the bridging header PCH is
created from the include tree directly. Setup the rewriter correctly
when embedding the bridging header into swift binary module.
rdar://125719747
In `getNormalInvocationArguments`, use a triple that corresponds to `ClangTarget`. This
matches the behavior of `addCommonInvocationArguments`.
rdar://124539816
An @_objcImpl extension with no category name *should* implement not only the class’s main @interface, but also any class extension @interfaces. Start making this true by making ObjCInterfaceAndImplementationRequest return all of these decls as the interfaces for such an implementation.
This commit doesn’t actually change Sema or IRGen to process the extra interfaces, so it’s NFC.
This reduces the memory overhead of objcImpl from one word per Decl to one bit per Decl, at the cost of making cache lookups slightly slower (but it will only be consulted once for non-objcImpl decls, which is by far the most common case).
Prior to emission of `.d` and `.swiftdeps` outputs. In implicit builds such dependencies are registered during the construction of the corresponding Clang module by the ClangImporter's built-in Compiler Instance. In explicit builds, since we load pre-built PCMs directly, we do not get to do so. So instead, manually register all `.h` inputs of Clang module dependnecies.
Resolves rdar://121354886
Previously, canImport lookup is not completely working with explicit
module due to two issues:
* For clang modules, canImport check still do a full modulemap lookup
which is repeated work from scanner. For caching builds, this lookup
cannot be performed because all modulemap and search path are dropped
after scanning.
* For swift module, if the canImport module was never actually imported
later, this canImport check will fail during the actual compilation,
causing different dependencies in the actual compilation.
To fix the problem, first unified the lookup method for clang and swift
module, which will only lookup the module dependencies reported by
scanner to determine if `canImport` succeed or not. Secondly, add all
the successful `canImport` check modules into the dependency of the
current module so this information can be used during actual
compilation.
Note the behavior change here is that if a module is only checked in
`canImport` but never imported still needs to be built. Comparing to
implicit module build, this can bring in additional clang modules if
they are only check inside `canImport` but should not increase work for
swift modules (where binary module needs to be on disk anyway) or the
most common usecase for `canImport` which is to check the same module
before importing.
rdar://121082031
This allows calling a C++ function with default arguments from Swift without having to explicitly specify the values of all arguments.
rdar://103975014
This is a forward-interop feature that wires up existing functionality for
synthesizing base class function calling to enable virtual function calling.
The general idea is to sythesize the pattern:
```
// C++ class:
struct S { virtual auto f() -> int { return 42; } };
// Swift User:
var s = S()
print("42: \(s.f())")
// Synthetized Swift Code:
extension S { func f() -> CInt { __synthesizedVirtualCall_f() } }
// Synthetized C/C++ Code:
auto __cxxVirtualCall_f(S *s) -> int { return s->f(); }
```
The idea here is to allow for the synthetized C++ bits from the Clang side to
handle the complexity of virtual function calling.
If a C++ type `Derived` inherits from `Base` privately, the public methods from `Base` should not be callable on an instance of `Derived`. However, C++ supports exposing such methods via a using declaration: `using MyPrivateBase::myPublicMethod;`.
MSVC started using this feature for `std::optional` which means Swift doesn't correctly import `var pointee: Pointee` for instantiations of `std::optional` on Windows. This prevents the automatic conformance to `CxxOptional` from being synthesized.
rdar://114282353 / resolves https://github.com/apple/swift/issues/68068
C++ `T& operator*()` is mapped to a Swift computed property `var pointee: T`.
Previously `var pointee` only had a getter, after this change it will also have a setter if the C++ type declares an overload of `operator*` that returns a mutable reference.
rdar://112471779
This fixes the automatic `std::unordered_map` conformance to CxxDictionary on Linux. Previously `std::unordered_map::const_iterator` was not auto-conformed to UnsafeCxxInputIterator because its `operator==` is defined on a templated base class of `const_iterator`.
rdar://105220600
Reformatting everything now that we have `llvm` namespaces. I've
separated this from the main commit to help manage merge-conflicts and
for making it a bit easier to read the mega-patch.
This is phase-1 of switching from llvm::Optional to std::optional in the
next rebranch. llvm::Optional was removed from upstream LLVM, so we need
to migrate off rather soon. On Darwin, std::optional, and llvm::Optional
have the same layout, so we don't need to be as concerned about ABI
beyond the name mangling. `llvm::Optional` is only returned from one
function in
```
getStandardTypeSubst(StringRef TypeName,
bool allowConcurrencyManglings);
```
It's the return value, so it should not impact the mangling of the
function, and the layout is the same as `std::optional`, so it should be
mostly okay. This function doesn't appear to have users, and the ABI was
already broken 2 years ago for concurrency and no one seemed to notice
so this should be "okay".
I'm doing the migration incrementally so that folks working on main can
cherry-pick back to the release/5.9 branch. Once 5.9 is done and locked
away, then we can go through and finish the replacement. Since `None`
and `Optional` show up in contexts where they are not `llvm::None` and
`llvm::Optional`, I'm preparing the work now by going through and
removing the namespace unwrapping and making the `llvm` namespace
explicit. This should make it fairly mechanical to go through and
replace llvm::Optional with std::optional, and llvm::None with
std::nullopt. It's also a change that can be brought onto the
release/5.9 with minimal impact. This should be an NFC change.
A recent refactoring uncovered two places where we could end up
importing a C++ field declaration as a property more than once:
1. Importing the declaration context of a field in C++ mode can then
go import all of the fields. In such a case, check that the field
we're importing didn't happen already, and bail out early if it did.
This is common practice in the Clang importer but wasn't happening here.
2. One caller to the function that imported a field from a C++ base
class into its inheriting class (as a computed property) wasn't
checking the cache, and therefore created a redundant version.
Fix both issues.
The Clang importer's Clang instance may be configured with a different (higher)
OS version than the compilation target itself in order to be able to load
pre-compiled Clang modules that are aligned with the broader SDK, and match the
SDK deployment target against which Swift modules are also built. In this case,
we must use the Swift compiler's OS version triple in order to generate the
binary as-requested.
This change makes 'ClangImporter' 'Implementation' keep track of a distinct
'TargetInfo' and 'CodeGenOpts' containers that are meant to be used by clients
in IRGen. When '-clang-target' is not set, they are defined to be copies of the
'ClangImporter's built-in module-loading Clang instance. When '-clang-target' is
set, they are configured with the Swift compilation's target triple and OS
version (but otherwise identical) instead. To distinguish IRGen clients from
module loading clients, 'getModuleAvailabilityTarget' is added for module
loading clients of 'ClangImporter'.
The notion of using a different triple for loading Clang modules arises for the
following reason:
- Swift is able to load Swift modules built against a different target triple
than the source module that is being compiled. Swift relies on availability
annotations on the API within the loaded modules to ensure that compilation
for the current target only uses appropriately-available API from its
dependencies.
- Clang, in contrast, requires that compilation only ever load modules (.pcm)
that are precisely aligned to the current source compilation. Because the
target triple (OS version in particular) between Swift source compilation and
Swift dependency module compilation may differ, this would otherwise result in
builtin multiple copies of the same Clang module, against different OS
versions, once for each different triple in the build graph.
Instead, with Explicitly-Built Modules, Swift sets a '-clang-target' argument
that ensures that all Clang modules participating in the build are built against
the SDK deployment target, matching the Swift modules in the SDK, which allows
them to expose a maximally-available API surface as required by
potentially-depending Swift modules' target OS version.
--------------------------------------------
For example:
Suppose we are building a source module 'Foo', targeting 'macosx10.0', using an
SDK with a deployment target of 'macosx12.0'. Swift modules in said SDK will be
built for 'macosx12.0' (as hard-coded in their textual interfaces), meaning they
may reference symbols expected to be present in dependency Clang modules at that
target OS version.
Suppose the source module 'Foo' depends on Swift module 'Bar', which then
depends on Clang module `Baz`. 'Bar' must be built targeting 'macosx12.0'
(SDK-matching deployment target is hard-coded into its textual interface). Which
means that 'Bar' expects 'Baz' to expose symbols that may only be available when
targeting at least 'macosx12.0'. e.g. 'Baz' may have symbols guarded with
'__MAC_OS_X_VERSION_MIN_REQUIRED >= __MAC_12_0'. For this reason, we use
'-clang-target' to ensure 'Baz' is built targeting 'macosx12.0', and can be
loaded by both 'Foo' and 'Bar'.
As a result, we cannot direclty use the Clang instance's target triple here and
must check if we need to instead use the triple of the Swift compiler instance.
Resolves rdar://109228963
If two different C++ structs have methods with the same name, both annotated with `SWIFT_COMPUTED_PROPERTY`, ClangImporter previously confused them when one of the structs referenced the other struct.
rdar://108990490 / resolves https://github.com/apple/swift/issues/65675
If a templated C++ class declares an operator as a member function, and is instantiated using a typedef or a using-decl on the C++ side, it previously could not be conformed to a Swift protocol that requires the operator function despite matching signatures.
This was due to a Swift name lookup issue: operators, unlike regular member functions, are found by doing an unqualified lookup. Since C++ class template specializations and their members are not added to `SwiftLookupTable`, when doing qualified lookup members are searched by looking at all of the members of the specialization and choosing the ones with matching names. With unqualified lookup, we cannot rely on knowing the right specialization and need to search for all the operators in a given module.
This change adds synthesized operator thunks to `SwiftLookupTable` to make them discoverable by unqualified lookup.
When importing a C++ struct that contains two methods that only differ in const-ness, we append `Mutating` to the name of the non-const method to make it possible to call from Swift unambiguously.
Unfortunately that logic was dependent on the order in which we import methods of a class: the `Mutating` suffix was added when another method with the same name was already imported.
This caused lookup failures, and the behavior was incorrect when the pair of methods return instances of an unsafe type: the const overload was renamed as `Unsafe` properly, but the non-const overload was not renamed.
If an operator is declared as a method of a templated class, we were failing to look it up during auto-conformance to `UnsafeCxxInputIterator`.
This fixes `Interop/Cxx/stdlib/use-std-map.swift` on Ubuntu.
rdar://102420290
`getValue` -> `value`
`getValueOr` -> `value_or`
`hasValue` -> `has_value`
`map` -> `transform`
The old API will be deprecated in the rebranch.
To avoid merge conflicts, use the new API already in the main branch.
rdar://102362022
When an anonymous enum is imported, its imported name is under some
circumstances derived from the type that it is backed by.
NS_REFINED_FOR_SWIFT is a macro that produces a __attribute__((swift_private))
that when attached to a declaration, the imported name of this
declaration should have two underscores prepended. When the name
anonymous enum is derived from another declaration, and said declaration
does not have the same swift private attribute, the __ is dropped. This
patch fixes this.
Instead of having out parameters for a couple of flags, create a small
struct with the type and the flags and return that struct inside the
Optional of importParameterType.
Additionally change the naming of some variables to make the function
and method code more similar.
Adapt the helper for figuring out parameter types for functions with the
code exclusive for figuring out method parameters. This includes special
code for handling dictionary subscripts, error parameters and completion
handlers.
The function parameters behaviour should not be modified, since in order
to import function parameters all of the new pieces of code should be
skipped following the value of the flags passed into the helper.
For method parameters, there is extensive changes, specially in the
cases of importing Obj-C++ methods that use C++ types, which were
supported for functions, but not so much for methods.
