[Dependency Scanning] Update Uses of `ModuleDeps::ClangModuleDeps`
https://github.com/llvm/llvm-project/pull/137421 changes the type of `ModuleDeps::ClangModuleDeps`. This PR updates Swift's use of this data structure to use the correct fields.
rdar://144794793
Our logic for doing the "declaration reference" classification was
unnecessarily convoluted, and did "unsafe" classification twice for
properties and subscripts that have other effects (throws/async) on
their getters. Simplify it.
The existing swift-cmake-options flag overwrites all flags computed by
build-script. Sometimes it is useful to be able to append additional
CMake flags without overwriting the existing flags.
This patch adds `--extra-swift-cmake-options` that adds the specified
flags to the Swift CMake configuration instead of overwriting them.
This also adds a similar `--extra-llvm-cmake-options`, which adds the
new flags to the end, allowing one to replace and overwrite CMake flags
that build-script computed.
Due to the parameter passing mechanisms in build-script-impl, while this
behavior would be useful for Swift, it is not immediately apparent how
one would best implement this at this time.
This patch removes the `SWIFT_RETURNED_AS_RETAINED_BY_DEFAULT`
annotation while maintaining the support for
`SWIFT_RETURNED_AS_UNRETAINED_BY_DEFAULT`. These type-level annotations
were initially introduced in
[PR-81093](https://github.com/swiftlang/swift/pull/81093) to reduce the
annotation burden in large C++ codebases where many C++ APIs returning
`SWIFT_SHARED_REFERENCE` types are exposed to Swift.
### Motivation
The original goal was to make C++ interop more ergonomic by allowing
type-level defaults for ownership conventions
for`SWIFT_SHARED_REFERENCE` types . However, defaulting to retained
return values (+1) seems to be problematic and poses memory safety
risks.
### Why we’re removing `SWIFT_RETURNED_AS_RETAINED_BY_DEFAULT`
- **Memory safety risks:** Defaulting to retained can potentially lead
to use-after-free bugs when the API implementation actually returns
`unowned` (`+0`). These errors are subtle and can be hard to debug or
discover, particularly in the absence of explicit API-level
`SWIFT_RETURNS_(UN)RETAINED` annotations.
- **Risky transitive behavior:** If a `SWIFT_SHARED_REFERENCE` type is
annotated with `SWIFT_RETURNED_AS_RETAINED_BY_DEFAULT`, any new C++ API
returning this type will inherit the retained behavior by default—even
if the API's actual return behavior is unretained. Unless explicitly
overridden with `SWIFT_RETURNS_UNRETAINED`, this can introduce a silent
mismatch in ownership expectations and lead to use-after-free bugs. This
is especially risky in large or evolving codebases where such defaults
may be overlooked.
- **Simpler multiple inheritance semantics:** With only one type-level
default (`SWIFT_RETURNED_AS_UNRETAINED_BY_DEFAULT`), we avoid
complications that can arise when multiple base classes specify
conflicting ownership defaults. This simplifies reasoning about behavior
in class hierarchies and avoids ambiguity when Swift determines the
ownership convention for inherited APIs.
### Why we’re keeping `SWIFT_RETURNED_AS_UNRETAINED_BY_DEFAULT`
- It still enables projects to suppress warnings for unannotated C++
APIs returning `SWIFT_SHARED_REFERENCE` types, helping to reduce noise
while maintaining clarity.
- It encourages explicitness for retained behavior. Developers must
annotate retained return values with `SWIFT_RETURNS_RETAINED`, making
ownership intent clearer and safer.
- The worst-case outcome of assuming unretained when the return is
actually retained is a memory leak, which is more tolerable and easier
to debug than a use-after-free.
- Having a single default mechanism improves clarity for documentation,
diagnostics, and long-term maintenance of Swift/C++ interop code.
This adds an `appendInterpolation` overload to
`DefaultStringInterpolation` that includes a parameter for providing a
default string when the value to interpolate is `nil`. This allows this
kind of usage:
```swift
let age: Int? = nil
print("Your age is \(age, default: "timeless")")
// Prints "Your age is timeless"
```
The change includes an additional fixit when optional values are
interpolated, with a suggestion to use this `default:` parameter.
Previously, `__attribute__((swift_attr("sending")))` would only be
resolved when attached to declarations. This patch expands it to be
a type attribute as well, which enables it to occur in the result and
parameter positions for blocks, function pointers, and lambdas.
Resolves rdar://148435359
...https://github.com/swiftlang/swift/pull/81280. The deleted test was
`test/FixCode/fixits-if-else.swift`. Resurrect it in a better place and
switch it to the diagnostic verifier, as it was intended to along with
other moved tests in that PR.
Updates the build.ps1 script to add the SwiftASN1 package support
to it's CMake build. This was caused by this dependency being added
to a module in SwiftPM that sourcekit-lsp imports.
Conditionalizing logic based on the exact output stream is brittle
since e.g the client may be writing to an intermediate buffer before
forwarding onto the output. For the ASTDumper itself, the client
already passes whether or not it expects a fully semantic dump, use
that instead. For `printContext`, the only client relying on this
was some `ResolvedRangeInfo` tests, but these don't actually care
about the computed discriminator, adjust the tests to not care.
