While building an initializer call the declaration reference
should have the same implicitness as the call when it doesn't
require thunking, otherwise don't attempt to mark autoclosures
as non-implicit because it could break assumptions elsewhere.
If a type in an `@_implements` attribute failed to resolve, Sema would assume it was because the type existed but wasn’t a protocol, even if there was another reason for the problem (such as the type not existing). Explicitly resolve the TypeRepr again through a path that will produce diagnostics.
When defaulting to main-actor isolation, types that have synthesized
conformances (e.g., for Equatable, Hashable, Codable) were getting
nonisolated members by default. That would cause compiler errors
because the conformances themselves defaulted to main-actor isolation
when their types were.
Be careful to only mark these members as 'nonisolated' when it makes
sense, and leave them to get the isolation of their enclosing type
when the conformance might have isolation. This ensures that one can
use synthesis of these protocols along with default main-actor mode.
There is a one-off trick here to force the synthesized CodingKeys to
be nonisolated, because the CodingKey protocol requires Sendable.
We'll separately consider whether to generalize this rule.
More of rdar://150691429.
Perform `Sendable` checking on parameter/result of the function
type when conversion between asynchroneous functions results in
a loss of global actor isolation attribute because access would
result in data crossing an isolation boundary.
This is a warning until Swift language mode 6.
Resolves: rdar://130168104
When we discover a textual module dependency which is a module which was not originally built from source using C++ interop (specifying '-formal-cxx-interoperability-mode=off'), 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.
Resolves rdar://150222155
Previously we would insert StringRefs that reference the keys in the
map, but that breaks if the invocation ever gets copied. Switch to
`std::string`.
rdar://148130166
Due to a bug in how macros on nodes imported from clang are evaluated,
their function body is not always type checked. This forces type
checking before silgen of a macro originating on a node imported from
clang, to prevent crashing in silgen.
rdar://150940383
The pthread APIs on FreeBSD do not include nullability APIs so the
pthread mutex APIs are imported as pointers to optional values.
Other platforms include nullability APIs and import the pthread APIs as
pointers to the mutex. Splitting the locking primitive type based on the
OS.
Fixes: rdar://150880976
Introduce install targets for the StringProcessing module. This is a
prerequisite for building a static variant of the standard library to
enable the statically linked early swift driver for Windows to
bootstrap.
Use it in the linux CI presets to set them to Debug mode and speed up
the linux CI, plus add a new preset which keeps building them in Release
mode.
I was looking at a passing linux CI run and saw the log timings at the
end: it takes [longer to build and test the swift-foundation repos than
to compile all 7k+ mostly C++ files in
LLVM](https://ci.swift.org/job/swift-PR-Linux/18996/console)!
```
--- Build Script Analyzer ---
Build Script Log: /home/build-user/build/.build_script_log
Build Percentage Build Duration (sec) Build Phase
================ ==================== ===========
9.2% 1132.94 Running tests for foundationtests
9.1% 1120.57 linux-x86_64-swift-build
9.0% 1104.2 Building llvm
7.2% 878.84 Running tests for swiftfoundationtests
6.5% 796.81 Running tests for swiftpm
5.6% 684.7 Building swiftpm
5.5% 667.92 linux-x86_64-swift-test
4.9% 597.64
```
Looking at the log, building swift-foundation in release mode takes a
long time, so let's see if changing it to debug mode helps. Some
background - the Foundation repos are built twice on the linux CI: once
by CMake, which is the version installed in the toolchain, then a second
time by SwiftPM purely for testing.
This pull only affects that second SwiftPM build for testing, which is
not shipped in the final toolchain but thrown away.
We build CMake on all platforms (except Darwin for an unknown reason) if CMake is not preinstalled. Since CMake 4.0 regresses certain build configurations, there's currently no way to build on Darwin without installing an older CMake version 3.x manually. This can be simplified if we build a pinned version of CMake consistently on all platforms.
As Python 3.5 added support for type hints and we require Python 3.6 or later, let's try to add a type hint to a single function so that development experience is slightly improved and we can test this feature in our code before applying it more widely. Editors with support for Python LSP servers can pick it and stop flagging this function or its
invocations as type errors.
_SwiftifyImport would expand with syntax errors if applied to a function
with anonymous parameters, because it would try to refer to parameters
using the name `_`. Detect these cases and create names for unnamed
parameters.
rdar://150955944
__counted_by (and __sized_by) expressions can have arbitrary C syntax
in them, such as:
void foo(int * __counted_by(*len) p, int *len);
When @_SwififyImport tries to generate Swift code for this, the
expression `*len` leads to a syntax error, since it isn't valid Swift.
This patch adds a check to ensure we only attach the Swiftify macro to
__counted_by expressions that are also syntactically valid in Swift.
rdar://150956352
Super surprised to see the build for swift test hardcoded in
the build.ps1 script instead of in the sourcekit-lsp repo.
At any rate, looks like I need to add the dependency on ASN1
here too.
This is to support changes in SwiftPM that add the dependency
which translates through to sourcekit-lsp.
https://github.com/swiftlang/swift-package-manager/pull/8610
Both the syntax and relative order of the LLVM `nocapture` parameter
attribute changed upstream in 29441e4f5fa5f5c7709f7cf180815ba97f611297.
To reduce conflicts with rebranch, adjust FileCheck patterns to expect
both syntaxes and orders anywhere the presence of the attribute is not
critical to the test. These changes are temporary and will be cleaned
up once rebranch is merged into main.
The parameter attribute was introduced in
5ece35df8586d0cb8c104a9f44eaae771de025f5 (llvm-project) and is expected
here according to the lowered function body.
Match it using a wildcard regex, since it is not relevant to this test.
This is intended to reduce future conflicts with rebranch.
This attribute was introduced in
7eca38ce76d5d1915f4ab7e665964062c0b37697 (llvm-project).
Match it using a wildcard regex, since it is not relevant to these
tests.
This is intended to reduce future conflicts with rebranch.
