Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SR-13859] Availability check fails on macOS Big Sur even if appropriate target is chosen. #56257

Closed
YOCKOW opened this issue Nov 16, 2020 · 6 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself

Comments

@YOCKOW
Copy link
Collaborator

YOCKOW commented Nov 16, 2020

Previous ID SR-13859
Radar rdar://problem/71446547
Original Reporter @YOCKOW
Type Bug
Environment

swift --version
Apple Swift version 5.3.1 (swiftlang-1200.0.41 clang-1200.0.32.8)
Target: x86_64-apple-darwin20.1.0

swift package --version
Swift Package Manager - Swift 5.3.0

OS
macOS Big Sur 11.0.1

Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug
Assignee None
Priority Medium

md5: ff382bc6885dcb70a6929ab9630082ef

Issue Description:

Overview

The following code is compiled successfully with `swiftc FH.swift`.
If, on the other hand, a Swift package contains the same file in Source directory, `swift build` will fail with message "error: protocol 'FH' requires 'write(contentsOf: )' to be available in macOS 10.15.0 and newer".

FH.swift

import Foundation

@available(macOS 10.15, iOS 13.0, watchOS 6.0, tvOS 13.0, *)
public protocol FH {
  mutating func write<D>(contentsOf data: D) throws where D: DataProtocol
}

@available(macOS 10.15, iOS 13.0, watchOS 6.0, tvOS 13.0, *)
extension FileHandle: FH {}

Package.swift

// swift-tools-version:5.3
// The swift-tools-version declares the minimum version of Swift required to build this package.

import PackageDescription

let package = Package(
    name: "FH",
    platforms: [
      .macOS(.v10_15),
      .iOS(.v13),
      .watchOS(.v6),
      .tvOS(.v13),
    ],
    products: [
        // Products define the executables and libraries a package produces, and make them visible to other packages.
        .library(
            name: "FH",
            targets: ["FH"]),
    ],
    dependencies: [
        // Dependencies declare other packages that this package depends on.
        // .package(url: /* package url */, from: "1.0.0"),
    ],
    targets: [
        // Targets are the basic building blocks of a package. A target can define a module or a test suite.
        // Targets can depend on other targets in this package, and on products in packages this package depends on.
        .target(
            name: "FH",
            dependencies: []),
    ]
)

Note

`swift build` did succeed on macOS Catalina.

@typesanitizer
Copy link

@swift-ci create

@YOCKOW
Copy link
Collaborator Author

YOCKOW commented Nov 17, 2020

  • `swiftc -target x86_64-apple-darwin20.1.0 FH.swift` (that is default of swiftc) succeeds.

  • `swiftc -target x86_64-apple-macos10.15 FH.swift` (that is used by Swift PM for this package) fails.

  • `swiftc -target x86_64-apple-macos10.10 FH.swift` fails.

  • `swiftc -target x86_64-apple-macos11.0 FH.swift` succeeds.

  • `swiftc -target x86_64-apple-macos10.15.7 FH.swift` (that is last release of Catalina) succeeds.

  • `swiftc -target x86_64-apple-macos10.99 FH.swift` succeeds. (Such OS doesn't exist, though...)

    Could it be that swift frontend is responsible for this issue?

@neonichu
Copy link
Member

What's even more confusing:

  • `swiftc -target x86_64-apple-macosx10.15.3 FH.swift` fails.

  • `swiftc -target x86_64-apple-macosx10.15.4 FH.swift` succeeds.

In any case, this doesn't seem to be an issue related to SwiftPM.

@YOCKOW
Copy link
Collaborator Author

YOCKOW commented Nov 18, 2020

@neonichu
Thank you for more trials.
I have changed the title of this issue.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@tshortli
Copy link
Contributor

This is expected behavior. The witness of the protocol requirement is defined in the SDK and has availability of macOS 10.15.4, which is later than the macOS 10.15 availability of the protocol FH. That means that between versions 10.15.0 and 10.15.4 the FileHandle type cannot satisfy the requirement.

The difference in behavior that you see is explained by the deployment target that is specified. When the deployment target is macOS 10.15.4 or higher then the requirement will always available.

@YOCKOW
Copy link
Collaborator Author

YOCKOW commented Sep 14, 2022

@tshortli
Thank you.
IIRC, the document said it was available on just macOS >=10.15 when this issue was opened.
I guess it was a documentation bug.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself
Projects
None yet
Development

No branches or pull requests

4 participants