3a200dee has a logic bug where we tried to conform C++ iterator types to `UnsafeCxxContiguousIterator` protocol based on their nested type called `iterator_category`. The C++20 standard says we should rely on `iterator_concept` instead.
https://en.cppreference.com/w/cpp/iterator/iterator_tags#Iterator_concept
Despite what the name suggests, we are not actually using C++ concepts in this change.
rdar://137877849
* [cxx-interop] Add Hashable conformance to imported enums
Previously, imported enums only conformed to RawRepresentable and Equatable,
so they could not be used as members of a Set or keys of a Dictionary.
This patch adds Hashable conformance to give them that ability,
as well as some test cases to clarify the expected behavior.
Existing test cases are updated to reflect this new conformance.
rdar://129713687
This adds a pair of Swift protocols that represents C++ iterator types conforming to `std::contiguous_iterator_tag` requirements. These are random access iterators that guarantee that the values are stored in consequent memory addresses.
This will be used to optimize usage of C++ containers such as `std::vector` from Swift, for instance, by providing an overload of `withContiguousStorageIfAvailable` for contiguous containers.
rdar://137877849
The Clang importer maps arbitrary attributes spelled with `swift_attr("...")`
over to Swift attributes, using the Swift parser to process those attributes.
Extend this mechanism to allow `swift_attr` to refer to an attached macro,
expanding that macro as needed.
When a macro is applied to an imported declaration, that declaration is
pretty-printed (from the C++ AST) to provide to the macro implementation.
There are a few games we need to place to resolve the macro, and a few more
to lazily perform pretty-printing and adjust source locations to get the
right information to the macro, but this demonstrates that we could
take this path.
As an example, we use this mechanism to add an `async` version of a C
function that delivers its result via completion handler, using the
`@AddAsync` example macro implementation from the swift-syntax
repository.
`__msvc_bit_utils.hpp` was added in a recent version of MSVC, and it is causing build errors for SwiftCompilerSources:
```
C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.39.33519\include\numeric:598:12: error: function '_Select_countr_zero_impl<unsigned long long, (lambda at C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.39.33519\include\numeric:598:55)>' with deduced return type cannot be used before it is defined
return _Select_countr_zero_impl<_Common_unsigned>([=](auto _Countr_zero_impl) {
```
This change references the `__msvc_bit_utils.hpp` header from the modulemap. Since we still need to support older versions of Visual Studio that do not provide `__msvc_bit_utils.hpp`, this also teaches ClangImporter to inject an empty header file named `__msvc_bit_utils.hpp` into the system include directory, unless it already exists.
rdar://137066642
Swift's own `Set` conforms to `ExpressibleByArrayLiteral`. This change conforms instantiations of C++ `std::set` to `ExpressibleByArrayLiteral` as well.
This makes it possible to pass an array literal as an argument to a function that takes a `std::set` as parameter.
rdar://137126325
Use IncludeTreeFileList instead of full feature CASFS for swift
dependency filesystem. This allows smaller CAS based VFS that is smaller
and faster. This is enabled by the CAS enabled compilation does not
need to iterate file system.
rdar://136787368
We should still try adding the overlays, even if we're asked not to
generate a diagnostic while doing so. That's slightly safer because
it means that we're less likely to find ourselves in a situation
where `swift-modulewrap` wants to use types from the C/C++ library
and can't.
rdar://115918181
The existing code will use paths for "iphoneos" because the triples for
macCatalyst are in the form "<arch>-apple-iosXX.yy-macabi", which the
code interprets as an iPhone triple. This seems to work in Xcode because
the "iphoneos" folder is always there. When building in open source,
this seems to work because it is also normal to have the iPhone SDK
configured. This is not the case if you want to build the macOS SDK in
isolation.
The code changes detect the macCatalyst environment from the triple and
use the "macosx" paths instead, otherwise it follows the same code path
as before. This matches many places in the CMakeLists.txt files in which
macCatalyst support pieces are only enabled when the SDK is macOS.
The modified function is also used for the libc modulemap of non-Darwin
platforms, but for those triples, the macCatalyst environment should not
be detected, so the libc modulemap should not be affected by this
change.
This is a followup to #76260 and #74994.
