Explanationion: Function pointer types wee always considered fragile in C++ mode,
this manifested as a regression when interfacing with glibc.
Issues: rdar://159184118
Original PRs: #84040
Risk: Low, this only removes a spurious error for library evolution.
Testing: Added a compiler test.
Reviewers: @egorzhdan
Explanation: The original code had the assumption we only import
modules. However, there is a flag to import an umbrella header in which
case the clang nodes have no owning module. This PR prevents a null
dereference in that case.
Issues: rdar://157489426
Original PRs: #83540
Risk: Low, added a check to avoid null dereference.
Testing: Added a compiler test.
Reviewers: @egorzhdan
We sometimes don't have the information in the modulemaps whether a
module requires ObjC or not. This info is useful for reverse interop.
This PR introduces a frontend flag to have a comma separated list of
modules that we should import as if they had "requires ObjC" in their
modulemaps.
Explanation: We the generated reverse interop headers to be valid C++,
so every declaration coming from an Obj-C module should be behind an
ifdef. Unfortunately, we do not always have this information but we do
know that our frameworks contain Obj-C code. So this PR makes sure every
entity coming from our frameworks are behind ifdef.
Issues: rdar://152836730
Original PRs: #83002
Risk: Low, the change is narrow and straightforward.
Testing: Added a compiler test.
Reviewers: @egorzhdan
Fix two IRGen tests that are failing on Android armv7 and disable eight ClangImporter, C++ Interop, and SILOptimizer tests, two of which that were already failing on other 32-bit platforms.
Explanation: C++ interop synthesizes certain forwarding functions in an
_ObjC module. This confuses MemberImportVisibility. This patch adds
logic to work this around by keeping a mapping between the synthesized
and the original function and looks up where the synthesized functions
belong to based on the original functions' parent module.
Scope: C++ forward interop when MemberImportVisibility is enabled.
Issues: rdar://154887575
Original PRs: #82840
Risk: Low, a narrow change makes getModuleContextForNameLookupForCxxDecl more
precise, and it is only used with MemberImportVisibility.
Testing: Added a compiler test.
Reviewers: @egorzhdan, @tshortli, @hnrklssn
C code is highly likely to want to use pointers as references between dependent
structs, and we would like to be able to readily map these to lifetime-dependent
Swift values. Making C types addressable-for-dependencies ensures that any function
producing a dependency on such a value receives a stable in-memory address for that
value, allowing borrows and inout accesses to always be representable as pointers.
rdar://153648393
Explanation: There was a null pointer dereference in reverse interop
when we wanted to expose an ObjC class written in Swift. There was a
crash during generating the scaffolding we do for Clang types. Since
the type is written in Swift, no such scaffolding is needed, this patch
skips this operation avoiding the null dereference.
Scope: Reverse C++ interop when exposing @ObjC classes written in Swift.
Issues: rdar://154252454
Original PRs: #82684
Risk: Low, the fix is narrow to the affected scenario.
Testing: Added a compiler test.
Reviewers: @egorzhdan
If a Swift class has a field, which has a closure type, which takes an instance of a `CF_OPTIONS`/`NS_OPTIONS` type as a parameter, the reverse interop logic would generate an invalid Objective-C++ header for such type.
This was discovered with UIKit's `UIControlState` type, which is declared with `NS_OPTIONS` in Objective-C, then renamed to `UIControl.State` with API Notes, and then re-exported to Objective-C++ via the generated header.
rdar://129622886
(cherry picked from commit e95c9ecffc)
When importing C++ methods, Swift always assumes that methods named `begin()` and `end()` are unsafe, since these methods commonly return iterator types that are inherently unsafe in Swift.
Some additional logic in Sema tries to diagnose usages of `.begin()` and `.end()` from Swift and suggest safe alternatives. That logic had a null pointer dereference bug.
rdar://153814676 / resolves https://github.com/swiftlang/swift/issues/82361
(cherry picked from commit 883ff18adb)
Integer literal expressions with types that are not of type `int` are
printed with a suffix to indicate the type (e.g. `123U` or `456L` for
`unsigned` and `long`). This is not valid syntax for integer literals in
Swift, so until we fully translate the count expr syntax to Swift we
need to avoid importing these count expressions.
Also fixes some -Werror related stuff in test cases.
rdar://154141719
(cherry picked from commit 374658a)
The runtime logic for printing a foreign reference type is behind `if #available(SwiftStdlib 6.2, *)`, which means it won't run on older versions of macOS, even if you use a newer Swift runtime.
rdar://153735437
(cherry picked from commit a292113ef2)
If a C++ namespace has redeclarations in a bridging header, printing AST for the namespace would crash the compiler. This is because such a redeclaration would not have an owning Clang module, and the AST printer did not account for that.
This change fixes the crash.
rdar://151715540
(cherry picked from commit cc9c51deea)
848fad00 introduced support for printing foreign reference types. It changes both the compiler and the runtime, and having the runtime change applied is required for the test to pass. Let's not try to run it with an old runtime.
This change also splits up a test for printing of value types from a test for printing of foreign reference types, since we don't have any runtime restrictions for value types.
rdar://153205860
(cherry picked from commit 62d56067c8)
Explanation: Shared references imported from C++ were not considered
safe. This is a widely used feature and this fix is blocking the users
from adopting strictly memory safe Swift.
Issue: rdar://151039766
Risk: Low, the fix only changes what declarations are considered safe.
Testing: Regression test added.
Original PR: #82203
Reviewer: @egorzhdan @fahadnayyar
Explanation: C++ template instantiations that are not behind type
aliases don't have corresponding Swift names that are both syntactically
and semantically valid types. This PR prevents generating swiftified
overloads for those types.
Issue: rdar://151422108
Risk: Low, we swiftify functions less often.
Testing: Regression test added.
Original PR: #81973
Reviewer: @hnrklssn
When instantiating templated functions with pointers to the templated type, the ClangImporter does not strip type sugar. This strips type sugar for bounds attributes, to make sure that they import the same regardless of whether they are parsed or not.
rdar://151041990
(cherry picked from commit 00afb8ba81)
Adds support for printing a C++ foreign reference in Swift.
Also skips metadata of private fields in C++ records imported as Swift classes, following up on #81035
(cherry-picked from 848fad0021)
Explanation: We did not handle this declaration kind. This PR makes sure we
mangle it the same way we do for the target declaration.
Issue: rdar://152841420
Risk: Low, the fix is small, localized, and straightforward.
Testing: Regression test added.
Original PR: #82144
Reviewer: @egorzhdan @hnrklssn @j-hui
Explanation: Some functions are implemented both in libc and libc++.
Clang uses the enable_if attribute to resolve otherwise ambiguous
functions calls. This PR makes the name lookup aware of this attribute.
Issue: rdar://152192945
Risk: Low, only C/C++ APIs with enable_if attributes are affected.
Testing: Regression test added.
Original PR: #82019
Reviewer: @hnrklssn
Explanation: We do not serialize the private macro generated swift
method's bodies which crashes the compiler. This PR skips generating
swiftified overloads to these private/protected method to work around
the crash.
Issue: rdar://152181531
Risk: Low, the change is straightforward.
Testing: Regression test added.
Original PR: #82016
Reviewer: @hnrklssn
Explanation: We did not have support to generate swiftified overload for
initializers. This PR adds that support.
Issue: rdar://152112660
Risk: Low, the feature is localized to swiftified overloads.
Testing: Regression test added.
Original PR: #81947
Reviewer: @hnrklssn
Previously we would not import decls containing these types. This was
not an issue, because they can only occur when -fbounds-safety or
-fexperimental-bounds-safety-attributes is passed to clang. When
SafeInteropWrappers is enabled we pass
-fexperimental-bound-safety-attributes to clang however, so these types
can now occur without the user specifying any -Xcc flags.
rdar://151611718
(cherry picked from commit ac068c2a6b)
These are split-file C++ tests, this is a problem for swift-syntax
because `.swift` tests get parsed for round-trip testing if
swift-syntax is located near swift.
(cherry picked from commit c019b669a1)
Textual interfaces for 'Darwin' built with recent compilers specify that it is built witout C++ interop enabled. However, to ensure compatibility with versions of the 'Darwin' module built with older compilers, we hard-code this fact. This is required to break the module cycle that occurs when building the 'Darwin' module with C++ interop enabled, where the underlying 'Darwin' clang module depends on C++ standard library for which the compiler brings in the 'CxxStdlib' Swift overlay, which depends on 'Darwin'.
When the compiler is building a module without a defined formal C++ interop mode (e.g. building a textual interface which specifies it was built without C++ interop enabled), avoid looking up the C++ standard library Swift overlay for it. This is required for the case of the Darwin module, for example, which includes headers which map to C++ stdlib headers when the compiler is operating in C++ interop mode, but the C++ standard library Swift overlay module itself depends on 'Darwin', which results in a cycle. To resolve such situations, we can rely on the fact that Swift textual interfaces of modules which were not built with C++ interop must be able to build without importing the C++ standard library Swift overlay, so we avoid specifying it as a dependency for such modules. The primary source module, as well as Swift textual module dependencies which were built with C++ interop will continue getting a direct depedency of the 'CxxStdlib' Swift module.
This was previously fixed in the dependency scanner for explicitly-built modules in https://github.com/swiftlang/swift/pull/81415.
Previously we did not remove count parameters if any count parameters
were shared between count expressions, or if any count expression
contained operations. Buffer sizes were also just checked to be larger
than or equal than the given count.
We now extract the count from Spans/BufferPointers whenever possible,
and store that value in a variable at the start of the function. If
multiple parameters share the same count, a bounds check is emitted to
make sure that they have the same size. Subspans can be used if one span
is larger than necessary.
The message in the bounds check is changed so that it includes the
expected and actual value, to aid in debugging.
This patch also fixes some incorrect indentation, and adds the
Whitespace.swift test case to act as a regression test in case the
indentation changes, since the other test cases don't use significant
whitespace.
rdar://151488820
rdar://151511090
rdar://146333006
rdar://147715799
(cherry picked from commit f5fa481205)
