Commit c82048559abf2d06c29bed1699dd1de473c925ff by achikin
[Dependency Scanning] Configure a thread-safe serialized diagnostics consumer for in-memory scans
This change introduces a thread-safe version of the 'SerializedDiagnosticConsumer' and refactors scanning compilation instance creation code to ensure this consumer gets added when the scanner query configuration command-line includes '-serialized-diagnostics-path' option.
Commit fe3cc6d024a21b0be126c5a0e42f555977e05742 by gaborh
[cxx-interop] Handle Unowned values in implicit value ctors
We usually have unowned values when dealing with foreign types. Make sure the implicit value ctors will do a +1 to balance the releases. In a release build we had a use after free over-releasing the object. In assert builds we had an assertion failure:
Assertion failed: (value->getOwnershipKind() == OwnershipKind::Guaranteed), function forBorrowedObjectRValue, file ManagedValue.h, line 181.
Commit 13d61b070910156b3e130c6c4b06ac1aa24eeb01 by shortlidge
Frontend: Require `-language-mode` option when emitting swiftinterfaces.
If a `.swiftinterface` file does not include an explicit `-language-mode` option (or its predecessor `swift-version`) and needs to be built as a dependency of a client compilation, then the invocation to build the module from interface would end up inheriting the language mode that the client code is built with. This can result in spurious type checking diagnostics or even mis-compilation. To ensure that a module interface is always built using the language mode that its source code was originally built with, require an explicit `-language-mode` option when emitting swiftinterface files.
This is a new case that comes up with `InlineArray`, since an `InlineArray` with unknown count but known trivial element type is trivial but still address-only due to its unknown size. We are inconsistent about whether we emit formal copies or not of these values; they should generally be unnecessary as long as the memory location of a value is sufficiently long-lived, but the SIL verifier still reasonably considers a `[take]` as an invalidation of the memory, even though at runtime a take is a no-op. Since the take is unnecessary, we can just not take when we copy out of a trivial address location. Fixes #84141 | rdar://160007939.
Commit 7d21bc332aca3dfac8aa81ee5c0fce3afae88875 by dgregor
[Embedded] Diagnose untyped throws as an Embedded Swift restriction
Untyped throws depends on existentials (`any Error`), and is therefore not available in Embedded Swift. Introduce a diagnostic that diagnoses any use of untyped throws, suggesting that one use typed throws instead.
Make this an opt-in diagnostic enabled with `-Wwarning EmbeddedRestrictions`, whether in Embedded Swift or not, using the "default ignore" flag on these new warnings. Document this new diagnostic group, and put the existing Embedded Swift error about weak/unowned references in it as well.
Part of the general push to have the type checker identify code that will not compile as Embedded Swift earlier, rdar://133874555.
Commit e12642f91735d9cee334e7aade3c784b5b7493bc by kateinoigakukun
[Legacy Driver][wasm] Pass `--table-base` to reserve low function addresses
WebAssembly does not have a reserved address space by default, so we need to explicitly reserve low addresses for extra inhabitants for enum types with pointer payloads. https://github.com/swiftlang/swift/pull/39300 added `--global-base` to reserve low data addresses, but we also need to reserve low function addresses with `--table-base` for function pointers because WebAssembly uses a separate address space for function pointers.
Commit d3e41e5f2bc6dd6580ad225e5a50a79031f8f546 by meghana_gupta
Update SwiftCompilerSources' OwnershipLiveness utility for borrow accessors
It uses a check on conformance to ForwardInstruction for walking down guaranteed forwarding uses. Since apply of borrow accessors cannot be represented as ForwardingInstruction, handle them separately.
Representing apply of borrow accessors for consistent handling in the optimizer is TBD.
Commit ac27f53c0455ec724b9ac492a3bee9e33a8ad124 by pyaskevich
[CSSimplify] Fix key path to function conversion to check key path requirements
`KeyPath` types now have conformance requirements placed on their `Root` and `Value` types which need to be checked even when there is a key path to function conversion involved, otherwise the solver would be accepting invalid code.
Note that without function conversion the requirements come from a type opened during assignment - https://github.com/swiftlang/swift/pull/80081/files.
Commit 865c643cac7ce82007c9ab0a30050f8f7c3b281b by dgregor
Suppress Embedded Restriction diagnostics in code that won't be compiled as Embedded
When emitting diagnostics for the Embedded Swift restrictions outside of Embedded Swift mode, consider `#if $Embedded` and `#if hasFeature(Embedded)` configurations. If the code where we would emit the diagnostic would be disabled in Embedded Swift by one of those checks, don't emit the diagnostic. This helps code that can compile either with Embedded or regular Swift stay within the restrictions on Embedded Swift.
Downgrade the new error in https://github.com/swiftlang/swift/pull/84244 to a warning.
The PR smoke test build is using a different build system that is failing to pass `-swift-version` arguments when building various stdlib modules. That needs to be fixed, but for now we also need to unblock CI.
![[Jenkins]](https://ci-external.swift.org/static/366f7f95/images/svgs/logo.svg){kind=logo}
