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-13718] swift test --generate-linuxmain doesn't grok conditionally compiled tests #4488

Open
lorentey opened this issue Oct 9, 2020 · 3 comments
Labels

Comments

@lorentey
Copy link
Member

lorentey commented Oct 9, 2020

Previous ID SR-13718
Radar rdar://problem/70268548
Original Reporter @lorentey
Type Bug

Attachment: Download

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

md5: 376ee6032ad73b2b9443fab165a3646a

Issue Description:

The swift-atomics package has some functionality that may be unavailable depending on properties of the underlying architecture. In particular, atomic strong references are only available when the target platform supports double-wide atomic primitives. Linux happens to prevent the use of double-wide atomics on x86_64 by default, so these features aren't normally available there.

This means that XCTestCase classes that test this functionality must be placed behind a compile-time `#if` conditional.

Unfortunately SwiftPM's handy `swift test --generate-linuxmain` functionality ignores conditional compilation directives, and unconditionally tries to register all tests, leading to a broken test manifest.

To reproduce, download the attached sample package and try to build its test on Linux.

// fooTests.swift
import XCTest
@testable import foo

#if !(os(Linux) && arch(x86_64)) || ENABLE_FOO
final class fooTests: XCTestCase {
    func testExample() {
        // This is an example of a functional test case.
        // Use XCTAssert and related functions to verify your tests produce the correct
        // results.
        XCTAssertEqual(foo().text, "Hello, World!")
    }

    static var allTests = [
        ("testExample", testExample),
    ]
}
#endif

Generated XCTestManifests.swift:

#if !canImport(ObjectiveC)
import XCTest

extension fooTests {
    // DO NOT MODIFY: This is autogenerated, use:
    //   `swift test --generate-linuxmain`
    // to regenerate.
    static let __allTests__fooTests = [
        ("testExample", testExample),
    ]
}

public func __allTests() -> [XCTestCaseEntry] {
    return [
        testCase(fooTests.__allTests__fooTests),
    ]
}
#endif

Output when attempting to build this on Ubuntu 20.04 with the Swift 5.3 toolchain:

root@a7f9a25d4f88:/host/foo# swift test 
/host/foo/Tests/fooTests/XCTestManifests.swift:4:11: error: cannot find type 'fooTests' in scope
extension fooTests {
          ^
/host/foo/Tests/fooTests/XCTestManifests.swift:4:11: note: cannot use module 'fooTests' as a type
extension fooTests {
          ^
/host/foo/Tests/fooTests/XCTestManifests.swift:15:18: error: module 'fooTests' has no member named '__allTests__fooTests'
        testCase(fooTests.__allTests__fooTests),
                 ^~~~~~~~ ~~~~~~~~~~~~~~~~~~~~
/host/foo/Tests/fooTests/XCTestManifests.swift:9:25: error: cannot find 'testExample' in scope
        ("testExample", testExample),
                        ^~~~~~~~~~~
@typesanitizer
Copy link

@swift-ci create

@neonichu
Copy link
Member

Since XCTest now has the ability to skip tests, wouldn't it be better to anyway move the conditional compilation into individual tests and report them as skipped?

@lorentey
Copy link
Member Author

That would work – however, the prospect of repeating the (nontrivial) compile-time condition across dozens/hundreds of test cases seemed too odious to swallow. (It wouldn't be the worst thing about the package, but I find that the list of such code-obfuscating workarounds is already quite long enough.) ;-)

For now, the package requires `--enable-test-discovery` on Linux.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@shahmishal shahmishal transferred this issue from apple/swift May 4, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants