Restructure the `visualc` module into `vcruntime` in order to help
expose the various components (SAL, vcruntime, ucrt, corecrt, STL) for C++
modularization. Include the `stdint.h` textually to deal with
redefinition of types in clang resources and MSVC.
If a C++ method returns a pointer and is not annotated with `returns_nonnull`, ClangImporter imports its return type as implicitly unwrapped optional `UnsafePointer<T>!`. This happens, for example, for `begin()`/`end()` methods of C++ collection types.
We would like to be able to conform C++ collections to `Swift.Sequence`/`Swift.Collection`/... To make this work, we create Swift protocols that require `func begin() -> RawIterator` and `func end() -> RawIterator` where `RawIterator` is an associated type.
The problem is that currently if `RawIterator` is `UnsafePointer<T>?`, `begin()`/`end()` methods that return an implicitly unwrapped optional `UnsafePointer<T>!` won't satisfy the requirements. This change fixes that.
Due to a now default-enabled `undef` pass (llvm/llvm-project
1b1c8d83d3567a60280291c0adb95d1d60335509), a whole bunch of interop
IRGen tests are failing due to missing `undefs`, even though they don't
matter in these tests at all. Add regex matches so that these tests just
check for the name and types of the functions they care about.
Temporarily disable the checks for mutable fields in a C++ struct. A better solution would be to use some heuristic to detect if a method mutates a mutable field, and allow the user to adjust mutability with the existing `nonmutating` annotation.
rdar://92621793
Previously, the clang importer marked all const methods as mutating whenever a C++ record had mutable fields. This change allows overriding this behavior by using the "nonmutating" swift_attr attribute.
Fixes SR-15907.
Make sure nested namespaces are added to the SwiftLookupTable when they are declared in a non-canonical redecl of the parent namespace.
This was blocking C++ interop adoption in SwiftCompilerSources.
When we look up a name directly, make sure we provide a scope, this is required when C++ interop is enabled.
This issue was exposed when we look up if an NSString is hashable. There is a special case for classes that inherit from NSObject, but we didn't see that, because we couldn't find NSObject (because lookup failed).
This addresses SR-15272.
When you have a function (e.g. 'foo') which is used in a constructor
initializer (e.g. constructor of some class 'Bar'), and you use the
constructor from swift code without directly using the function (e.g.
Bar's ctor is used from swift but foo isn't, foo is used from Bar's ctor),
you will get a link error. My fix is as follows:
When walking the clangAST to be imported, make sure you look at each
CXXCtorInitializer for each CXXConstructorDecl you see.
The Clang Importer when C++ interop is not enabled, disambigate an Obj-C
class and protocol that are named the same by appending `Protocol` to
the protocol. This was not happening when C++ interop was enabled, but
should also apply to Obj-C++ modules.
The fix is providing an starting scope for the search, which the C++
name lookup need to actually find the similarly named counterpart.
Includes a test to avoid this problem creeping in again, and locally it
did not break any other tests.
The main point of this change is to make sure that a shared function always has a body: both, in the optimizer pipeline and in the swiftmodule file.
This is important because the compiler always needs to emit code for a shared function. Shared functions cannot be referenced from outside the module.
In several corner cases we missed to maintain this invariant which resulted in unresolved-symbol linker errors.
As side-effect of this change we can drop the shared_external SIL linkage and the IsSerializable flag, which simplifies the serialization and linkage concept.
We used to only emit "destroy" and "initializeWithCopy". This commit adds support for emitting "assignWithCopy", "initializeWithTake" and "assignWithTake".
This commit adds very basic support for importing and calling base class methods, getting and setting base class fields, and using types inside of base classes.
There are three major changes here:
1. The addition of "SILFunctionTypeRepresentation::CXXMethod".
2. C++ methods are imported with their members *last*. Then the arguments are switched when emitting the IR for an application of the function.
3. Clang decls are now marked as foreign witnesses.
These are all steps towards being able to have C++ protocol conformance.
