This is a futile attempt to discourage future use of getType() by
giving it a "scary" name.
We want people to use getInterfaceType() like with the other decl kinds.
When computing the path for a non-architecture specific resource, we
would append the architecture unconditionally if `-sdk` is used. This
would result in the path being miscomputed with the architecture or the
architecture duplicated if it was architecture specific.
Found by inspection.
This Objective-C method
```
- (void)stream:(NSStream *)aStream
handleEvent:(NSStreamEvent)eventCode;
```
should be imported as
```
optional func stream(
_ aStream: Stream,
handle eventCode: Stream.Event)
```
and not
```
optional func stream(
_ aStream: Stream,
handleEvent eventCode: Stream.Event)
```
in order to stay compatible with Objective-C interop mode.
rdar://113208675
In libc++, `pair()` and `pair(_T1 const& __t1, _T2 const& __t2)` are templated with `enable_if`, so these initializers are not imported into Swift.
There should be a way to call `std.pair.init` from Swift, so this change makes sure Swift synthesizes a memberwise initializer for `std.pair`.
rdar://113135110
`IncrementalProcessing` is now a language option
`IncrementalExtensions`, which also means it is now part of the module
hash.
When compiling a clang module, the output file path would be generated
in the `BeginSourceFile` prior to `enableIncrementalProcessing` being
called on the preprocessor. The hash would then be generated again when
compiling the module (after the `enableIncrementalProcessing` call) and
included in the PCM, leading to a mismatch between the path and the hash
in the module.
This could be fixed by moving `enableIncrementalProcessing` above
`BeginSourceFile`, but now that it's an option we can instead just add
it to the invocation arguments.
Resolves rdar://112993659.
When Swift fails to import a member of a struct, it checks to see if this member could affect the memory layout of the struct, and if it can, Swift doesn't synthesize the memberwise initializer for this struct. This logic was overly restrictive and treated templated using-decls as potentially affecting the memory layout of the struct.
rdar://113044949
I discovered this when experimenting with `std::map::iterator`, which has a const overload of `operator*` that returns a non-const reference, and does not have a const overload of `operator*`.
rdar://112471779
This is an inheritor of the existing `UnsafeCxxInputIterator` protocol, with the only difference being the ability to mutate `var pointee` via a non-const `operator*()`.
This is needed to support mutable subscripts for `std::map` via `CxxDictionary`.
rdar://105399019
This prevented `std::vector<std::string>` from being auto-conformed to `CxxRandomAccessCollection`.
If an iterator type is templated, and does not have an explicit instantiation via a typedef or a using-decl, its specialization will not have an owning Clang module. Make sure we treat it as a part of the Clang module that owns the template decl.
rdar://112762768 / resolves https://github.com/apple/swift/issues/67410
Windows logic for determining address-only type layout for a C++ type is now unified with other platforms.
However, this means that on Windows, a C++ type with a custom destructor, but a default copy constructor
is now loadable, even though it's non-trivial. Since Swift does not support such type operations at the
moment (it can't be yet destroyed), mark such type as unavailable in Swift instead, when building for
the Windows target.
This fixes the Windows miscompilation related to such types when they were passed indirectly to C++
functions even though they're actually passed directly.
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
