Description

Multiple @available attributes for the same platform are accepted when type-checking source code. However, module interface emission combines them into a single attribute with duplicate platform entries. The generated interface then fails the compiler's own verification.

This reproduces without availability macros or external dependencies.

Reproduction

Save as Probe.swift:

@available(macOS 11.0, *)
@available(macOS 15.0, *)
public func api() {}

Source type-checking succeeds:

xcrun swiftc -language-mode 6 \
  -target arm64-apple-macosx11.0 \
  -typecheck Probe.swift

Emit a module interface:

xcrun swiftc -language-mode 6 \
  -target arm64-apple-macosx11.0 \
  -emit-module -enable-library-evolution \
  -module-name Probe \
  -emit-module-path Probe.swiftmodule \
  -emit-module-interface-path Probe.swiftinterface \
  Probe.swift

This exits with code 1. The generated interface contains:

@available(macOS 11.0, macOS 15.0, *)
public func api()

Diagnostic:

Probe.swiftinterface:9:2: error: version for macOS already specified

Expected behavior

Emit a valid interface that preserves the effective availability, for example:

@available(macOS 15.0, *)
public func api()

Source-level availability checking already requires macOS 15.0, regardless of the order of the two attributes.

Environment

• Xcode 27.0, build 27A266a
• macOS 26.6.2, Apple Silicon
• Swift language mode 6

Apple Swift version 6.4 (swiftlang-6.4.0.34.1 clang-2100.3.34.1)

Additional information

• Reversing the attributes still produces an invalid interface.
• Using separate long-form attributes, such as @available(macOS, introduced: 11.0), reproduces the same failure.
• Also reproduced with Apple Swift 6.3.3 from Xcode 26.6.
• This prevents binary framework consumers from loading the emitted textual interface.

Motivation: platform-specific restrictions on a shared availability macro

The repeated platform entries can arise naturally when combining a shared availability macro with a stricter requirement on one platform.

For example, a library defines its baseline availability as:

AvailabilityMacro=MyLib_v1_0:iOS 13.0, macOS 10.15, tvOS 13.0, watchOS 6.0

Most APIs use this baseline. An API that requires a newer macOS version can add a platform-specific restriction:

@available(macOS 15.0, *)
@available(MyLib_v1_0, *)
public func api() {}

The intended availability is iOS 13.0, macOS 15.0, tvOS 13.0, and watchOS 6.0. This lets the library reuse its baseline macro while expressing additional restrictions where needed, without defining a separate macro for every combination of platform requirements.

After macro expansion, both attributes contain a macOS requirement. Source-level checking applies the stricter requirement, but interface emission retains both macOS entries in a single attribute, producing an invalid .swiftinterface.

The reproduction above omits the macro to isolate the underlying interface-emission issue.