The Clang importer was directly calling into the parser to parse the
attribute (or modifier) within swift_attr. Aside from being gross, this
isn't possible with ASTGen.
Instead, teach ParseSourceFileRequest to deal with modifiers in the
same way that the Clang importer was hardcoding, and have the Clang
importer pull the attributes/modifiers off of the "missing"
declaration introduced by the request.
One benefit of this approach is that we're only parsing each
swift_attr source buffer once, then cloning the attributes each time
it's used, so we should be doing less work overall.
Fixes rdar://139119159.
This reverts commit 3066bd6919.
This re-lands a change after it got reverted because of a regression in the build of SwiftCompilerSources.
rdar://136838485
This PR adds a variadic macro that builds a SwiftAttr string containing
the names of the template type parameters that need to be escapable for
the type to be considered escapable. It also adds logic to interpret
this annotation.
rdar://139065437
Introduce a number of fixes to allow us to fully use declarations that
are produced by applying a peer macro to an imported declarations.
These changes include:
* Ensuring that we have the right set of imports in the source file
containing the macro expansion, because it depends only on the module
it comes from
* Ensuring that name lookup looks in that file even when the
DeclContext hierarchy doesn't contain the source file (because it's
based on the Clang module structure)
Expand testing to be sure that we're getting the right calls,
diagnostics, and generated IR symbols.
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
