This reverts commit e60ae24052 and fix
non-deterministic failures introduced by the commit.
Fix two issues when attempting to testing parallel scanning using
`swift-scan-test` tools:
* Make sure the BumpPtrAllocator in ScanningService is thread-safe so
there are no race condition when a new slab is allocated.
* Make sure the output of `swift-scan-test` only written from one
thread. This prevents some race conditions when writing to the same
raw_fd_ostream.
rdar://167760262
Currently, dependency scanner is not reporting the redirecting files
that are baked inside swift-frontend for platform support. This causes
dependency scanner returns virtual path for those files, and
swift-driver/build-system will not be able to correct validate the files
on incremental build, causing incremental build to be almost clean
builds.
This behavior issue is caused by the dependency scanning file system
layer inside clang dependency scanner that caches stats. If the
redirecting files are created underneath the layer, the real path is
lost. This fixes the issue by moving the redirecting files above the
caching layer using `-ivfsoverlay` option.
In addition to that, this commit also unifies how clang importer and
clang dependency scanner initiate the VFS, making the logic much
simpler.
When Objective-C interoperability was disabled, we were not including
the default implementations of _ObjectiveCBridgeable for
_SwiftNewtypeWrapper-conforming types in the standard library. This
meant that the _ObjectiveCBridgeable conformance of newtype'd imported
types was broken.
Enable those implementations by dropping the `#if _runtime(_ObjC)`
check and drop the Objective-C interop requirement for the
corresponding test.
Fixes rdar://167570178.
Add execution tests verifying that NS_CLOSED_ENUM (imported as @frozen)
properly validates raw values in init?(rawValue:), returning nil for
invalid values instead of creating poison enum instances.
These tests currently fail, demonstrating issue #85701 where invalid
raw values are accepted and later crash in switch statements.
If we try to import this in ObjC interop mode:
```objc
typedef CF_OPTIONS(uint32_t, MyFlags) {
...
} CF_SWIFT_NAME(MyCtx.Flags);
struct MyStruct {
MyFlags flags;
...
} CF_SWIFT_NAME(MyCtx);
```
ClangImporter tries to import `MyCtx/MyStruct` before it imports
`MyFlags` (via `importDeclContextOf()`), which in turn tries to import
`MyFlags` again due to the `flags` field. The existing cycle-breaking
mechanism prevents us from looping infinitely, but leads us to import
two copies of the Swift `EnumDecl`, which can cause errors later during
CodeGen.
~~This patch adds an assertion to catch such issues earlier, and breaks
the cycle by checking the cache again.~~ This patch no longer does so
because that caused issues beyond the scope of this patch.
rdar://162317760
Make sure the destination type actually conforms to the corresponding
builtin literal protocol before attempting to import it. We may want
to consider allowing any type that conforms to the non-builtin literal
protocol, but I want to keep this patch low risk and just ensure we at
least don't crash for now.
rdar://156524292
It hoists `destroy_value` instructions for non-lexical values.
```
%1 = some_ownedValue
...
last_use(%1)
... // other instructions
destroy_value %1
```
->
```
%1 = some_ownedValue
...
last_use(%1)
destroy_value %1 // <- moved after the last use
... // other instructions
```
In contrast to non-mandatory optimization passes, this is the only pass which hoists destroys over deinit-barriers.
This ensures consistent behavior in -Onone and optimized builds.
Whenever we have a reference to a foreign function/variable in SIL, use
a mangled name at the SIL level with the C name in the asmname
attribute. The expands the use of asmname to three kinds of cases that
it hadn't been used in yet:
* Declarations imported from C headers/modules
* @_cdecl @implementation of C headers/modules
* @_cdecl functions in general
Some code within the SIL pipeline makes assumptions that the C names of
various runtime functions are reflected at the SIL level. For example,
the linking of Embedded Swift runtime functions is done by-name, and
some of those names refer to C functions (like `swift_retain`) and
others refer to Swift functions that use `@_silgen_name` (like
`swift_getDefaultExecutor`). Extend the serialized module format to
include a table that maps from the asmname of functions/variables over
to their mangled names, so we can look up functions by asmname if we
want. These tables could also be used for checking for declarations
that conflict on their asmname in the future. Right now, we leave it
up to LLVM or the linker to do the checking.
`@_silgen_name` is not affected by these changes, nor should it be:
that hidden feature is specifically meant to affect the name at the
SIL level.
The vast majority of test changes are SIL tests where we had expected
to see the C/C++/Objective-C names in the tests for references to
foreign entities, and now we see Swift mangled names (ending in To).
The SIL declarations themselves will have a corresponding asmname.
Notably, the IRGen tests have *not* changed, because we generally the
same IR as before. It's only the modeling at the SIL lever that has
changed.
Another part of rdar://137014448.
This test was only run with NDK 28 locally, so we didn't realize this
feature won't work with Bionic in LTS NDK 27, which is what the CI uses.
We will re-enable this with the next LTS NDK release, when we switch the
Android CI to use that next LTS NDK.
Replace the `here` part of the generic exportability diagnostic for
variables with: `in a property declaration marked public or in a
'@frozen' or '@usableFromInline' context`.
The full diagnostic now looks like:
```
error: cannot use struct 'ImportedType' in a property declaration marked
public or in a '@frozen' or '@usableFromInline' context;
'HiddenDependency' has been imported as implementation-only
```
This should be improved further to support implicitly exported memory
layouts in non-library-evolution and embedded.
This is a tiny improvement to the diagnostic messages emitted by Swift. Conventionally we wrap identifiers, such as module names, in single quotes in the diagnostic messages.
rdar://138812125
Specifically, this means importing getters defined via swift_async_name. This
just ensures that they are treated just like any other imported objc async
function with completion handler.
rdar://156985950
These are tests that fail in the next commit without this flag. This
does not add -verify-ignore-unrelated to all tests with -verify, only
the ones that would fail without it. This is NFC since this flag is
currently a no-op.
A "permanently enabled" availability domain is one that has been declared
always available and is also simultaneously has either an attribute that
makes it deprecated or universally unavailable.
Emit fix-its that remove (or update) `@available` attributes that restrict
availability in a permanently enabled domain. Also, emit warnings about
`if #available` queries that always return true because they check a
permanently enabled domain.
Resolves rdar://157601761.
Internally-imported bridging headers must not leak outside of the Swift
module. Don't serialize their contents, and make sure we can still
import the module even if the bridging header has been removed.
It's very, very easy to make a mistake that will cause broken
serialized modules. Until that's no longer true, at least tell folks
that they are heading into uncharted waters, as we do with
`@_implementationOnly` imports.
C++ namespaces always get imported into the bridging header's module
for Reasons. Exempt them from internal-import checking, since we get
checking for the namespace members that are actually used.
When using an internal import for a bridging header, semantically treat
the contents of the bridging header, and anything that it imports, as
if they were imported internally. This is the actual semantic behavior
we wanted from internally-imported bridging headers.
This is the main semantic checking bit for rdar://74011750.
The flags "-import-bridging-header" and "-import-pch" import a bridging
header, treating the contents as a public import. Introduce
"internal-" variants of both flags that provide the same semantics,
but are intended to treat the imported contents as if they came in
through an internal import. This is just plumbing of the options for
the moment.
