Previously, they were being parsed as top-level code, which would cause
errors because there are no definitions. Introduce a new
GeneratedSourceInfo kind to mark the purpose of these buffers so the
parser can handle them appropriately.
Previous behavior had the scanner simply proceed if the header input of a binary Swift module dependency could not be resolved on the filesystem
Resolves rdar://139736789
SwiftDeclSynthesizer::makeDefaultArgument does not create substituion map while
creating the implicit FuncDecl which leads to TypeChecker complaining about
the absence when there are type parameters. Avoid importing such C++ functions for now.
We were searching for types in the Swift stdlib by name, just to get the names back from the types. Let's just return the type name without performing the search.
No user-facing change intended.
While private and protected fields coming from C++ cannot be accessed from Swift, they can affect Swift typechecking.
For instance, the Swift typechecker mechanism that adds implicit `Sendable` conformances works by iterating over all of the struct's fields and checking whether all of them are `Sendable`. This logic was broken for C++ types with private fields, since they were never accounted for. This resulted in erroneous implicit `Sendable` confromances being added.
Same applies for `BitwiseCopyable`.
In addition to this, ClangImporter used to mistakenly mark all C++ structs that have private fields as types with unreferenceable storage, which hampered optimizations.
As a side effect of this change, we now also provide a better diagnostic when someone tries to access a private C++ field from Swift.
rdar://134430857
Improve clang importor so it can directly load explicit module even
implicit module is enabled. This is a special configuration used by lldb
because lldb sometimes need to load additional modules when binding
external types. This provide the path in clang importer that can load
explicit module without locating the clang module map, while fallback to
module map lookup when implicit module is needed.
Certain build configurations of SwiftCompilerSources now incorrectly treat `BridgedSwiftObject` as a non-copyable type, causing compiler errors. This is a short-term workaround for these errors.
rdar://138924133
This makes sure that different template instantiations of `std::tuple` get distinct Swift type names.
Similar to aa6804a3.
This also refactors `swift::importer::printClassTemplateSpecializationName` to follow a proper visitor pattern for the C++ template arguments.
rdar://139435937
C++ swift::Parser is going to be replaced with SwiftParser+ASTGen.
Direct dependencies to it should be removed. Before that, remove
unnecessary '#include "swift/Parse/Parser.h"' to clarify what actually
depends on 'swift::Parser'.
Split 'swift::parseDeclName()' et al. into the dedicated files.
ClangImporter already had some logic in place to rename certain unsafe
C++ methods to make sure their name indicates unsafety. With the recent
push for auditability, we have a new @unsafe attribute so we can
automate parts of the auditing process. This patch makes sure whenever
we rename a method as "Unsafe", we also add the @unsafe attribute.
Today ParenType is used:
1. As the type of ParenExpr
2. As the payload type of an unlabeled single
associated value enum case (and the type of
ParenPattern).
3. As the type for an `(X)` TypeRepr
For 1, this leads to some odd behavior, e.g the
type of `(5.0 * 5).squareRoot()` is `(Double)`. For
2, we should be checking the arity of the enum case
constructor parameters and the presence of
ParenPattern respectively. Eventually we ought to
consider replacing Paren/TuplePattern with a
PatternList node, similar to ArgumentList.
3 is one case where it could be argued that there's
some utility in preserving the sugar of the type
that the user wrote. However it's really not clear
to me that this is particularly desirable since a
bunch of diagnostic logic is already stripping
ParenTypes. In cases where we care about how the
type was written in source, we really ought to be
consulting the TypeRepr.
This change refactors the top-level dependency scanning flow to follow the following procedure:
Scan():
1. From the source target under scan, query all imported module identifiers for a *Swift* module. Leave unresolved identifiers unresolved. Proceed transitively to build a *Swift* module dependency graph.
2. Take every unresolved import identifier in the graph from (1) and, assuming that it must be a Clang module, dispatch all of them to be queried in-parallel by the scanner's worker pool.
3. Resolve bridging header Clang module dpendencies
4. Resolve all Swift overlay dependencies, relying on all Clang modules collected in (2) and (3)
5. For the source target under scan, use all of the above discovered module dependencies to resolve all cross-import overlay dependencies
When Swift imports C++ template class instantiations, it generates a human-readable Swift name for each instantiation.
Having name collisions causes multiple Swift type with the same name, which confuses the compiler.
`MyClass<int[]>` and `MyClass<long[]>` were both being imported as `MyClass<_>` into Swift. This patch fixes that:
* `MyClass<int[]>` is now imported as `MyClass<[CInt]>`
* `MyClass<int[123]>` is now imported as `MyClass<Vector<CInt, 123>>`
rdar://138921102
The semantics of returning independent value already matches what
immortal lifetimes are within Swift. This patch makes sure this
annotation works as expected with non-escapable types.
rdar://137671642
Occasionally, when the Swift compiler emits a diagnostic for a construct
that was imported from C++ we get a diagnostic with unknown location.
This is a bad user experience. It is particularly bad with the
borrow-checker related diagnostics. This patch extends the source
location importing to declarations in ClangImporter. There are some
invariants enforced by the Swift compile, e.g., a source range is
comprised of two valid source locations or two invalid ones. As a
result, this patch adds approximate source locations to some separators
like braces or parens that are not maintained by Clang. Having slightly
incorrect ranges in this case is better than emitting unknown source
locations.
This removes a longstanding workaround in the import logic for C++ structs:
Swift assumed that if a C++ struct has no copy constructor that is explicitly deleted, then the struct is copyable. This is not actually correct. This replaces the workaround with a proper check for the presence of a C++ copy constructor.
rdar://136838485
Based on feedback in PR https://github.com/swiftlang/swift/pull/69460, enabling indexing for synthesized decls because they are usable by users and make sense to appear in the indexstore.
Sets `synthesized` on some additional decls:
- derived `hashInto(...)`
- Objc properties and methods derived from Objc protocols
https://github.com/apple/swift/issues/67446
Swift should never try to import C++ structs that are not fully defined. This is because Clang can't synthesize implicit members of such types, which might be necessary for Swift, e.g. a copy constructor.
This adds an assertion that makes sure that C++ structs are considered to be fully defined by Clang. This condition should already be satisfied.
In GenCall, fix the IR gen for C++ method calls as under MSVC as the
calling conventions for free functions and C++ methods can be
different. This also fixes the missing inreg (on sret arguments)
issues on Windows ARM64. Also refactor to use CGFunctionInfo
returnInfo isSretAfterThis to detect when to reorder the sret and the
this arguments under MSVC.
In ClagImporter, don't drop the return type for the compound
assignment operators such as operator+= when the return value is a
reference so that the CGFunctionInfo will be correctly indicate an
indirect return for the compound assignment operators.
This type is non-copyable and non-moveable despite having a defaulted move constructor. It cannot currently be expressed in Swift. Let's not try to import it into Swift.
rdar://138123064 / resolves https://github.com/swiftlang/swift/issues/76809
When a type is explicitly annotated as escapable or non-escapable it has
requirements about the lifetime annotations. This patch introduces
diagnostics to detect that.
