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
This adds support for `swift_name` attribute being used with C++ types that are declared within namespaces, e.g.
```
__attribute__((swift_name("MyNamespace.MyType.my_method()")))
```
Previously import-as-member would only accept a top-level unqualified type name.
rdar://138934888
While this made sense in the distant past where the scanning service provided backing storage for the dependency cache, it no longer does so and now makes for awkard layering where clients get at the service via the cache. Now the cache is a simple data structure while all the clients that need access to the scanning service will get it explicitly.
- 'SwiftModuleScanner' will now be owned directly by the 'ModuleDependencyScanningWorker' and will contain all the necessary custom logic, instead of being instantiated by the module interface loader for each query
- Moves ownership over module output path and sdk module output path directly into the scanning worker, instead of the cache
Initially, the compiler rejected building dependencies that contained OS
versions in an invalid range. However, this happens to be quite
disruptive, so instead allow it and request that these versions be
implicitly bumped based on what `llvm::Triple::getCanonicalVersionForOS`
computes.
resolves: rdar://153205856
This teaches ClangImporter to respect the `_Nonnull`/`_Nullable` arguments on templated function parameters.
Previously Swift would only import a non-annotated function overload. Using an overload that has either `_Nonnull` or `_Nullable` would result in a compiler error. The non-annotated overload would get imported with incorrect nullability: Swift would always assume non-null pointers, which was inconsistent with non-templated function parameters, which are mapped to implicitly unwrapped optionals.
With this change all three possible overloads are imported, and all of them get the correct nullability in Swift.
rdar://151939344
This patch makes sure we don't get warnings in strict memory safe mode
when using shared references. Those types are reference counted so we
are unlikely to run into lifetime errors.
rdar://151039766
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
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.
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
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
Import simple CPP macro aliases as aliases in Swift. Extend the macro
importer to import the following construct:
```
#define alias aliasee
```
as the following Swift construct:
```
@_transparent @inline(__always)
var alias: type(of: aliasee) {
aliasee
}
```
This improves the QoI for Windows where there is a universal define
(`UNICODE`) which normally is used for translating APIs between ANSI and
Unicode variants, e.g.:
```
#if defined(UNICODE)
#define MessageBox MessageBoxW
#else
#define MessageBox MessageBoxA
#endif
```
Global variables which are non-const also have a setter synthesized:
```
@_transparent @inline(__always)
var alias: type(of: aliasee) {
get { return aliasee }
set { aliasee = newValue }
}
```
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.
When building against the static standard library, we should define
`SWIFT_STATIC_STDLIB` to indicate to the shims that the declarations
should be giving hidden visibility and default DLL storage. This is
required to ensure that these symbols are known to be `dso_local` when
compiling to avoid an unnecessary look up through the PLT/GOT or the
indirection through the synthesized `__imp_` symbol and the IAT. This
corrects a number of incorrect code generation cases on Windows with the
static standard library.
The generated overloads do not get seralized and later on the compiler
crashes due to the missing body of the SILFunction. This PR works this
problem around by not generating these overloads. We plan to address the
serialization issue later.
rdar://152181531
While I could not trigger a scenario where the generated macro triggers
a compilation error, the generated code is definitely not valid Swift.
rdar://151422108
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
Unfortunately, there is no common abstraction for initializers and
functions in SwiftSyntax, so this PR rolls our own. Alternatively, we
could probably achieve something similar with a new protocol, but we
only needed a handful of fields so this change keeps it simple.
rdar://152112660
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 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
