Especially in an explicit modules project, LLDB might not know all the
search paths needed to imported the on disk header.
rdar://157063577
(cherry picked from commit a6678476d8)
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
Adds an access control field for each imported module identified. When multiple imports of the same module are found, this keeps track of the most "open" access specifier.
LookupOverloadedBinOp stores `Args` for later use, so store the
backing array on the stack instead of using a temporary.
This fixes a crash that appeared under some build configurations.
Related to rdar://154291418
(cherry picked from commit 75ac27dc3d)
This is a follow-up to https://github.com/swiftlang/swift/pull/82085
which made it so async variant doesn't get `@Sendable` inferred because
the proposal specified that inference should happen only on completion
handler parameter type of a synchronous variant of an imported API.
This runs into implementation issues related to thunking in some
cases were async convention expects the type of a completion handler
to match exactly for both variants of the imported API.
Resolves: rdar://154695053
(cherry picked from commit 30f0fa8d75)
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)
When improving the speed of dependency scanning when the new clang API
to speed up bridging, some unintended change was introduced. This
restore the scanner to the behavior before #81454
rdar://153851818
(cherry picked from commit cebe173ada)
Functions that are isolated to a global actor don't have completion
handlers imported as `@Sendable`. Main actor isolated functions with
completion handlers that are always called on the main actor is a
very common Objective-C pattern, and this carve out will eliminate
false positive warnings in the cases where the main actor annotation
is missing on the completion handler parameter.
Resolves: rdar://149811049
(cherry picked from commit ab227b401d)
This lifts the check for the feature flag up into the `importParameterType`
from `importType` and means that completion handler type for `async` variant
is no longer gains `@Sendable` attribute.
(cherry picked from commit 74471e858b)
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
Currently, when we jump-to-definition for decls that are macro-expanded
from Clang imported decls (e.g., safe overloads generated by
@_SwiftifyImport), setLocationInfo() emits a bongus location pointing to
a generated buffer, leading the IDE to try to jump to a file that does
not exist.
The root cause here is that setLocationInfo() calls getOriginalRange()
(earlier, getOriginalLocation()), which was not written to account for
such cases where a macro is generated from another generated buffer
whose kind is 'AttributeFromClang'.
This patch fixes setLocationInfo() with some refactoring:
- getOriginalRange() is inlined into setLocationInfo(), so that the
generated buffer-handling logic is localized to that function. This
includes how it handles buffers generated for ReplacedFunctionBody.
- getOriginalLocation() is used in a couple of other places that only
care about macros expanded from the same buffer (so other generated
buffers not not relevant). This "macro-chasing" logic is simplified
and moved from ModuleDecl::getOriginalRange() to a free-standing
function, getMacroUnexpandedRange() (there is no reason for it to be
a method of ModuleDecl).
- GeneratedSourceInfo now carries an extra ClangNode field, which is
populated by getClangSwiftAttrSourceFile() when constructing
a generated buffer for an 'AttributeFromClang'. This could probably
be union'ed with one or more of the other fields in the future.
rdar://151020332
(cherry picked from commit 44aba1382d)
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)
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
Create a path that swift-frontend can execute an uncached job from
modules built with CAS based explicit module build. The new flag
-import-module-from-cas will allow an uncached build to load module
from CAS, and combined with source file from real file system to build
the current module. This allows quick iterations that bypasses CAS,
without full dependency scanning every time in between.
rdar://152441866
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)
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.
Update availability for CxxSpan<->Span, fix lifetimebound on parameters
with reference type
Because swift-ide-test doesn't care about typechecking,
std-span-interface.swift passed despite containing 2 separate errors.
This updates the test file to properly exercise the entire compilation
pipeline for the macro expansions, by running swift-frontend
-emit-module and calling each macro expansion.
The first issue was that CxxSpan initializers taking [Mutable]Span still
had their availability set to Swift 6.2+, even after back-deploying
caused [Mutable]Span to have availability back to Swift 5.0. Since
_SwiftifyImport expansions copy the availbility of Span, this resulted
in the macro expansions calling unavailable initializers. Interestingly
enough, this manifested itself in the form of a tripped assert in SIL
verification, because although we do now typecheck the expansions from
_SwiftifyImport, the compilation can still keep going after
`shouldEmitFunctionBody` returns false: the macro expansion declaration
is still there, but is now missing its definition, despite not being
external.
The second issue was when parameters with C++ reference types were
annotated with `[[clang::lifetimebound]]`. For parameters with a type
that is `Escapable`, this is normally done using `@lifetime(borrow
foo)`. However C++ reference parameters are imported as `inout`, which
requires the `@lifetime(&foo)` syntax.
rdar://151493400
rdar://151678415
(cherry picked from commit 262a53f599)
On creation, 'ClangImporter' adds overlay modulemap files for non-modular platform libraries (e.g. glibc, libstdc++), which allows Swift code to import and use those libraries.
This change adds the same filesystem overlay to dependency scanning queries by applying them to the filesystem instantiated for each depndency scanning worker. Without these overlays EBM builds cannot discover and use non-modular system libraries on non-Darwin platforms.
Resolves rdar://151780437
Swift nodes imported from clang don't have doc comments carried over,
but IDEs are clever enough to fetch the comments from the associated
clang node. The swift node in the macro expansion from _SwiftifyImport
doesn't have a clang node directly associated with it however.
This patch adds the same comment from the clang node to the
_SwiftifyImport macro invocation node. Since the macro has access to
this node, it can easily copy over its leading trivia.
For now the comment is not altered at all, meaning @param still remains
even if the parmeter is removed.
rdar://151346977
(cherry picked from commit 6534b9b14f)
Use the underlying compiler invocation inside module scanning result to
speed up the clang module dependency bridging. This avoids converting
cc1 arguments to compiler invocation and back, just to modify the cc1
arguments needed for building PCM using swift-frontend.
rdar://151705822
(cherry picked from commit 391446d4b3)
Use `resetBenignCodeGenOptions()` from clang dependency scanner to clear
the swift explicit module build cc1 arguments. This fixes the problem
that CurrentWorkingDirectory is leaking through
`-fcoverage-compilation-dir` that can cause extra module variants when
caching is enabled. This also avoid the duplicating the logics for
clearing CodeGen options inside Swift.
rdar://151395300
(cherry picked from commit 531227d4b9)
After removing the CASFS implementation for clang modules, there is no
need to capture clang extra file that sets up the VFS for the clang
modules since all content imported by ClangImporter is dependency
scanned and available via include-tree. This saves more ClangImporter
instance when caching is enabled.
Update the test to check that clang content found via `-Xcc` VFS options
can currently work without capture the headermaps and vfs overlays.
(cherry picked from commit 1506a0d495)
Using IncludeTree::FileList to concat the include tree file systems that
are passed on the command-line. This significantly reduce the
command-line size, and also makes the cache key computation a lot
faster.
rdar://148752988
(cherry picked from commit 201e4faea7)
The NS_OPTIONS macro sometimes uses a pattern where it loosely
associates a typedef with an anonymous enum via a shared underlying
integer type (emphasis on "loosely"). The typedef is marked as
unavailable in Swift so as to not cause name ambiguity when we associate
the anonymous enum with said typedef. We use unavailability as
a heuristic during the import process, but that conflates NS_OPTIONS
with NS_ENUMs that can be marked as unavailable for entirely unrelated
reasons.
That in and of itself is fine, because the import logic is general
enough to handle both cases, but we have an assertion that seems to be
unaware of this scenario, and trips on unavailable NS_ENUMs. (In those
cases, the typedef points to the enum rather than the underlying integer
type.) This patch fixes the assertion to be resilient against such cases
by looking through the enum a typedef refers to.
rdar://150399978
(cherry picked from commit 80db05455f)
