A non functional change replacing auto with
Decl* for some declarations using ClangImporter::Implementation::importDecl.
Increases clarity and makes subsequent planned changes easier.
The Swift runtime and the concurrency module both use -mcx16, so there seems to be little point in not enabling it for Swift code in general.
This allows packages like swift-atomics to rely on double wide atomics always being available.
https://bugs.swift.org/browse/SR-13781
Note: we only lazily load the result if it's a record, because otherwise it's trivial to load when importing the function. Also, we still eagerly import operator's results types.
This change makes ClangImporter import some C++ member functions as non-mutating, given that they satisfy two requirements:
* the function itself is marked as `const`
* the parent struct doesn't contain any `mutable` members
`get` accessors of subscript operators are now also imported as non-mutating if the C++ `operator[]` satisfies the requirements above.
Fixes SR-12795.
Previously a namespace declaration was imported along with all of its redeclarations, and their members were added to a single Swift extension. This was problematic when a single namespace is declared in multiple modules – the extension belonged to only one of them.
For an example of this, try printing a module interface for `std.string`/`std.iosfwd` – it will be empty, even though the declarations from those modules are actually imported into Swift correctly.
This change makes sure that when we're importing different redeclarations of the same namespace, we're adding them as separate extensions to appropriate modules.
Pass a wrapped VFS down into `clang::createInvocationFromCommandLine` so
that the working directory is set and then used in the underlying Clang
`CompilerInstance`.
Fixes the possibility of differing modules hashes when the same
arguments are used in Clang directly vs from the importer.
Resolves rdar://79376364
Before this change, we always use the Swift target triple to instantiate the internal
Clang instance. When loading a Swift module from the textual interface, we may pick up
a lower target triple to use to build the Swift module because the target is hard-coded
in the textual interface file. This implies we may end up building multiple versions of the
same Clang module, one for each target triple of the loading Swift module.
This change adds a new frontend flag -clang-target to allow clients to specify a
consistent clang target to use across the Swift module boundaries. This value won't change
because it's not part of .swiftinterface files.
swift-driver should pass down -clang-target for each frontend invocation, and its value should be
identical to -target.
Related to: rdar://72480261
If there is a `-fmodule-map-file` argument whose file doesn’t exist and SwiftShims is not in the module cache, we fail to build it, because clang throws an error about the missing module map. This causes SourceKit to drop all semantic functionality, even if the missing module map isn’t required.
To work around this, drop all `-fmodule-map-file` arguments with missing files from the clang importer’s arguments, reporting the eror that `clang` would throw manually.
Fixes rdar://77449671
Project versions are embedded in the .tbd files of Clang frameworks. This patch teaches the compiler
to check the desired version specified in `canImport` against the project version in .tbd file. The
condition returns true if the Clang module on disk has a version number greater or equal to the one from `canImport`
condition; it returns false otherwise.
Part of rdar://73992299
canImport should be able to take an additional parameter labeled by either version or
underlyingVersion. We need underlyingVersion for clang modules with Swift overlays because they
have separate version numbers. The library users are usually interested in checking the importability
of the underlying clang module instead of its Swift overlay.
Part of rdar://73992299
Commit the platform definition and build script work necessary to
cross-compile for arm64_32.
arm64_32 is a variant of AARCH64 that supports an ILP32 architecture.
The diagnostics system doesn't allow a diagnostic to be emitted while
another diagnostic is in flight. Doing so will cause an assertion in
the diagnostics machinery.
There's a longstanding cycle here when diagnostics emission
pretty-prints declarations that are imported from a Clang module, and
the Clang Importer emits a diagnostic. Squash this cycle forcefully,
dropping the diagnostic that the Clang importer would emit.
A change in the new clang branch seems to have caused it to start applying SwiftNameAttrs to forward declarations. We have apparently always tried to add these forward declarations to the lookup tables in PCH files, but never diagnosed the resulting failures because they did not have SwiftNameAttrs. Now they do, so we started emitting incorrect warnings.
We *probably* don’t need to process these at all, but there’s a risk of unintended behavior changes from that; instead, this commit takes a conservative approach and simply suppresses the warnings like we always have.
Fixes rdar://74710976.
This PR makes it possible to instantiate C++ class templates from Swift. Given a C++ header:
```c++
// C++ module `ClassTemplates`
template<class T>
struct MagicWrapper {
T t;
};
struct MagicNumber {};
```
it is now possible to write in Swift:
```swift
import ClassTemplates
func x() -> MagicWrapper<MagicNumber> {
return MagicWrapper<MagicNumber>()
}
```
This is achieved by importing C++ class templates as generic structs, and then when Swift type checker calls `applyGenericArguments` we detect when the generic struct is backed by the C++ class template and call Clang to instantiate the template. In order to make it possible to put class instantiations such as `MagicWrapper<MagicNumber>` into Swift signatures, we have created a new field in `StructDecl` named `TemplateInstantiationType` where the typechecker stores the `BoundGenericType` which we serialize. Deserializer then notices that the `BoundGenericType` is actually a C++ class template and performs the instantiation logic.
Depends on https://github.com/apple/swift/pull/33420.
Progress towards https://bugs.swift.org/browse/SR-13261.
Fixes https://bugs.swift.org/browse/SR-13775.
Co-authored-by: Dmitri Gribenko <gribozavr@gmail.com>
Co-authored-by: Rosica Dejanovska <rosica@google.com>
This synchronizes the C/C++ standard that Swift uses for the clang
importer with the defaults of the clang compiler.
The default for the C standard remains the same at `gnu11`. However, if
clang was built with a different default C standard, that will be
preferred.
The default for the C++ standard is moved to C++14. Although this is a
reduced version, it matches what the current clang compiler defaults to.
Additionally, if the user built clang with a different C++ standard,
that standard would be preferred.
Although the C++ support is a bit more conservative, the idea is that we
can be certain that the clang version fully supports this standard as it
it the default version for clang.
The test change made here replaces the use of `auto` type parameters to
templates which is a C++17 feature. Reduce the example to a C++14
equivalent.
The clang version seems to behave differently in preventing the
synthesis of the constexpr value. This persists into the newer clang
releases as well. This is reasonable as the value does not need to be
exported necessarily and users will be able to materialize the value.
We use the optimizer to ensure that the value is inlined.
This also repairs the C++ interop tests on Windows with a newer C++
runtime from Microsoft.
This simply extracts the shared portion of the language version setup.
The state of the ObjC interop determines if we are in ObjectiveC or C
mode or ObjectiveC++ or C++ mode depending on C++ interop. However, if
Objective-C interop is enabled, we must enable ARC and set the ObjC
runtime version according to the target. This simply shares more of the
setup and is meant as a simplification for pairing the language version.
