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-1243] 'swift test' results in major error on linux when using Swift binaries from 4/12 #5458

Closed
swift-ci opened this issue Apr 15, 2016 · 25 comments

Comments

@swift-ci
Copy link
Contributor

Previous ID SR-1243
Radar None
Original Reporter rolivieri (JIRA User)
Type Bug
Status Resolved
Resolution Done

Attachment: Download

Environment

Ubuntu 15

Additional Detail from JIRA
Votes 5
Component/s Compiler, Package Manager, XCTest
Labels Bug, CompilerCrash, Linux
Assignee None
Priority Medium

md5: 34cb01e963ad83912b058178803a296a

Issue Description:

Using the Swift binaries from 4/12, we can no longer execute “swift test” on Linux (Ubuntu 15) under the following scenario: A helper function is defined inside a class that extends XCTestCase and receives as a parameter a structure defined in the Swift module that is being tested. If the helper function is commented out or the parameter type of the function is changed to, say String, then 'swift test' executes with no errors.

To reproduce the error, please use the Swift package in the zip file. See the verifyService() method defined in the MainTests.swift file. Executing 'swift test' on OS X will work just fine but on Ubuntu 15, it will throw the error below:

root@1ff2e6466639:~/Swift-cfenv# swift test
Linking .build/debug/CFEnvironment.xctest
swift: /home/buildnode/jenkins/workspace/oss-swift-package-linux-ubuntu-15_10/swift/include/swift/Serialization/ModuleFile.h:361: Status swift::ModuleFile::error(Status): Assertion `(!FileContext || issue != Status::Malformed) && "error deserializing an individual record"' failed.
0 swift 0x00000000031c8dd8 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 40
1 swift 0x00000000031c75d6 llvm::sys::RunSignalHandlers() + 54
2 swift 0x00000000031c9906
3 libpthread.so.0 0x00007fd4f4b5ad10
4 libc.so.6 0x00007fd4f34a2267 gsignal + 55
5 libc.so.6 0x00007fd4f34a3eca abort + 362
6 libc.so.6 0x00007fd4f349b03d
7 libc.so.6 0x00007fd4f349b0f2
8 swift 0x0000000000cb0529 swift::ModuleFile::resolveCrossReference(swift::ModuleDecl*, unsigned int) + 6057
9 swift 0x0000000000ca25a1 swift::ModuleFile::getDecl(llvm::PointerEmbeddedInt<unsigned int, 31>, llvm::Optional<swift::DeclContext*>) + 11121
10 swift 0x0000000000ca8e64 swift::ModuleFile::getType(llvm::PointerEmbeddedInt<unsigned int, 31>) + 1300
11 swift 0x0000000000ca902d swift::ModuleFile::getType(llvm::PointerEmbeddedInt<unsigned int, 31>) + 1757
12 swift 0x0000000000ca9281 swift::ModuleFile::getType(llvm::PointerEmbeddedInt<unsigned int, 31>) + 2353
13 swift 0x0000000000ca9294 swift::ModuleFile::getType(llvm::PointerEmbeddedInt<unsigned int, 31>) + 2372
14 swift 0x0000000000ca6bd0 swift::ModuleFile::getDecl(llvm::PointerEmbeddedInt<unsigned int, 31>, llvm::Optional<swift::DeclContext*>) + 29088
15 swift 0x0000000000cae9eb swift::ModuleFile::readMembers(llvm::SmallVectorImpl<swift::Decl*>&) + 251
16 swift 0x0000000000cb2a83 swift::ModuleFile::loadAllMembers(swift::Decl*, unsigned long) + 227
17 swift 0x000000000108fef6 swift::IterableDeclContext::loadAllMembers() const + 86
18 swift 0x000000000107f040 swift::NominalTypeDecl::getMembers() const + 16
19 swift 0x00000000010c3f30 swift::NominalTypeDecl::lookupDirect(swift::DeclName, bool) + 80
20 swift 0x00000000010c2a42 swift::DeclContext::lookupQualified(swift::Type, swift::DeclName, unsigned int, swift::LazyResolver*, llvm::SmallVectorImpl<swift::ValueDecl*>&) const + 3522
21 swift 0x0000000000ebf4c0
22 swift 0x0000000000ebf312 swift::TypeChecker::lookupMember(swift::DeclContext*, swift::Type, swift::DeclName, swift::OptionSet<swift::NameLookupFlags, unsigned int>) + 386
23 swift 0x0000000000f03802 swift::constraints::ConstraintSystem::lookupMember(swift::Type, swift::DeclName) + 290
24 swift 0x0000000000f69773 swift::constraints::ConstraintSystem::performMemberLookup(swift::constraints::ConstraintKind, swift::DeclName, swift::Type, swift::constraints::ConstraintLocator*, bool) + 2579
25 swift 0x0000000000f6b165 swift::constraints::ConstraintSystem::simplifyMemberConstraint(swift::constraints::Constraint const&) + 437
26 swift 0x0000000000f6c224 swift::constraints::ConstraintSystem::simplifyConstraint(swift::constraints::Constraint const&) + 68
27 swift 0x0000000000f04457 swift::constraints::ConstraintSystem::addConstraint(swift::constraints::Constraint*, bool, bool) + 23
28 swift 0x0000000000f4db75
29 swift 0x0000000000f56fb3
30 swift 0x0000000001023a48
31 swift 0x0000000001025a31
32 swift 0x0000000001023a88
33 swift 0x0000000001023f87
34 swift 0x0000000001023a2b
35 swift 0x0000000001025a31
36 swift 0x0000000001023a88
37 swift 0x0000000001020abe swift::Expr::walk(swift::ASTWalker&) + 46
38 swift 0x0000000000f4a178 swift::constraints::ConstraintSystem::generateConstraints(swift::Expr*) + 200
39 swift 0x0000000000e6e625 swift::TypeChecker::solveForExpression(swift::Expr*&, swift::DeclContext*, swift::Type, swift::FreeTypeVariableBinding, swift::ExprTypeCheckListener*, swift::constraints::ConstraintSystem&, llvm::SmallVectorImpl<swift::constraints::Solution>&, swift::OptionSet<swift::TypeCheckExprFlags, unsigned int>) + 245
40 swift 0x0000000000e74ae0 swift::TypeChecker::typeCheckExpression(swift::Expr*&, swift::DeclContext*, swift::Type, swift::ContextualTypePurpose, swift::OptionSet<swift::TypeCheckExprFlags, unsigned int>, swift::ExprTypeCheckListener*) + 576
41 swift 0x0000000000ee5570
42 swift 0x0000000000ee4be6 swift::TypeChecker::typeCheckTopLevelCodeDecl(swift::TopLevelCodeDecl*) + 134
43 swift 0x0000000000ea89ed swift::performTypeChecking(swift::SourceFile&, swift::TopLevelContext&, swift::OptionSet<swift::TypeCheckingFlags, unsigned int>, unsigned int) + 1117
44 swift 0x0000000000ce03bf swift::CompilerInstance::performSema() + 3295
45 swift 0x0000000000792819
46 swift 0x0000000000791943 frontend_main(llvm::ArrayRef<char const*>, char const*, void*) + 2643
47 swift 0x000000000078d0d7 main + 2567
48 libc.so.6 0x00007fd4f348da40 __libc_start_main + 240
49 swift 0x000000000078ac79 _start + 41
Stack dump:
0. Program arguments: /root/swift-DEVELOPMENT-SNAPSHOT-2016-04-12-a-ubuntu15.10/usr/bin/swift -frontend -c -primary-file /root/Swift-cfenv/Tests/LinuxMain.swift -target x86_64-unknown-linux-gnu -disable-objc-interop -I /root/Swift-cfenv/.build/debug -g -emit-module-doc-path /tmp/LinuxMain-25b8bd.swiftdoc -module-name CFEnvironment -emit-module-path /tmp/LinuxMain-25b8bd.swiftmodule -o /tmp/LinuxMain-25b8bd.o

  1. While type-checking expression at [/root/Swift-cfenv/Tests/LinuxMain.swift:5:1 - line:7:2] RangeText="XCTMain([
    testCase(MainTests.allTests)
    ])"
  2. While loading members for 'MainTests' at <invalid loc>
  3. While deserializing 'verifyService' (FuncDecl Fix 'dependable' typo in DevelopingPackages.md #7)
  4. While deserializing decl Improve integer literal initializer for Specifier #21 (XREF)
  5. Cross-reference to module 'CFEnvironment'
    ... Service
    <unknown>:0: error: unable to execute command: Aborted
    <unknown>:0: error: compile command failed due to signal (use -v to see invocation)
    <unknown>:0: error: build had 1 command failures
    error: exit(1): /root/swift-DEVELOPMENT-SNAPSHOT-2016-04-12-a-ubuntu15.10/usr/bin/swift-build-tool -f /root/Swift-cfenv/.build/debug.yaml test
    root@1ff2e6466639:~/Swift-cfenv#
@modocache
Copy link
Mannequin

modocache mannequin commented Apr 17, 2016

Thanks for the report, and for the project that reproduces the error! I've confirmed that the tests succeed on OS X using an .xctoolchain I created using a commit from Swift master on April 14:

$ /Library/Developer/Toolchains/swift-LOCAL-2016-04-14-a.xctoolchain/usr/bin/swift --version
Apple Swift version 3.0-dev (LLVM 752e1430fc, Clang 3987718dae, Swift 1d78da3ebf)
Target: x86_64-apple-macosx10.9
$ /Library/Developer/Toolchains/swift-LOCAL-2016-04-14-a.xctoolchain/usr/bin/swift-build --chdir ~/Downloads/Swift-cfenv
Compile Swift Module 'CFEnvironment' (1 sources)
$ /Library/Developer/Toolchains/swift-LOCAL-2016-04-14-a.xctoolchain/usr/bin/swift-test --chdir ~/Downloads/Swift-cfenv
Compile Swift Module 'CFEnvironmentTestSuite' (1 sources)
Linking /Users/bgesiak/Downloads/Swift-cfenv/.build/debug/CFEnvironment.xctest/Contents/MacOS/CFEnvironment
Test Suite 'All tests' started at 2016-04-17 11:09:25.238
Test Suite 'CFEnvironment.xctest' started at 2016-04-17 11:09:25.239
Test Suite 'MainTests' started at 2016-04-17 11:09:25.239
Test Case '-[CFEnvironmentTestSuite.MainTests testCase1]' started.
In testCase1...
Test Case '-[CFEnvironmentTestSuite.MainTests testCase1]' passed (0.002 seconds).
Test Suite 'MainTests' passed at 2016-04-17 11:09:25.241.
     Executed 1 test, with 0 failures (0 unexpected) in 0.002 (0.002) seconds
Test Suite 'CFEnvironment.xctest' passed at 2016-04-17 11:09:25.241.
     Executed 1 test, with 0 failures (0 unexpected) in 0.002 (0.002) seconds
Test Suite 'All tests' passed at 2016-04-17 11:09:25.241.
     Executed 1 test, with 0 failures (0 unexpected) in 0.002 (0.003) seconds

I had a bit of trouble building swiftpm on Linux using the latest commits on master (/cc @mxcl]:

swiftpm $ git rev-parse HEAD
af229127b79a0320f8ba999ffcf38042618ca29e
swiftpm $ cd ../swift 
swift $ utils/build-script -R --llbuild --swiftpm
# ...
--- bootstrap: note: building self-hosted 'swift-build': env SWIFT_EXEC=/home/modocache/GitHub/apple/build/Ninja-ReleaseAssert/swiftpm-linux-x86_64/debug/swiftc SWIFT_BUILD_PATH=/home/modocache/GitHub/apple/build/Ninja-ReleaseAssert/swiftpm-linux-x86_64 /home/modocache/GitHub/apple/build/Ninja-ReleaseAssert/swiftpm-linux-x86_64/debug/swift-build-stage1 -Xlinker -rpath -Xlinker $ORIGIN/../lib/swift/linux
/home/modocache/GitHub/apple/build/Ninja-ReleaseAssert/swiftpm-linux-x86_64/debug.yaml:7:1: error: unexpected trailing top-level section
default: main
^
<unknown>:0: error: unable to load build file
error: exit(1): /home/modocache/GitHub/apple/build/Ninja-ReleaseAssert/swiftpm-linux-x86_64/debug/swift-build-tool -f /home/modocache/GitHub/apple/build/Ninja-ReleaseAssert/swiftpm-linux-x86_64/debug.yaml

However, running the sample project on Linux using the 4-12 snapshot produces the error you describe:

$ ~/Downloads/swift-DEVELOPMENT-SNAPSHOT-2016-04-12-a-ubuntu15.10/usr/bin/swift build --chdir ~/Downloads/Swift-cfenv
Compiling Swift Module 'CFEnvironment' (1 sources)
$ ~/Downloads/swift-DEVELOPMENT-SNAPSHOT-2016-04-12-a-ubuntu15.10/usr/bin/swift test --chdir ~/Downloads/Swift-cfenv
Compiling Swift Module 'CFEnvironmentTestSuite' (1 sources)
Linking /home/modocache/Downloads/Swift-cfenv/.build/debug/CFEnvironment.xctest
swift: /home/buildnode/jenkins/workspace/oss-swift-package-linux-ubuntu-15_10/swift/include/swift/Serialization/ModuleFile.h:361: Status swift::ModuleFile::error(Status): Assertion `(!FileContext || issue != Status::Malformed) && "error deserializing an individual record"' failed.
0  swift           0x00000000031c8dd8 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 40
1  swift           0x00000000031c75d6 llvm::sys::RunSignalHandlers() + 54
2  swift           0x00000000031c9906
3  libpthread.so.0 0x00007f2d83445d10
4  libc.so.6       0x00007f2d81d8d267 gsignal + 55
5  libc.so.6       0x00007f2d81d8eeca abort + 362
6  libc.so.6       0x00007f2d81d8603d
7  libc.so.6       0x00007f2d81d860f2
8  swift           0x0000000000cb0529 swift::ModuleFile::resolveCrossReference(swift::ModuleDecl*, unsigned int) + 6057
9  swift           0x0000000000ca25a1 swift::ModuleFile::getDecl(llvm::PointerEmbeddedInt<unsigned int, 31>, llvm::Optional<swift::DeclContext*>) + 11121
10 swift           0x0000000000ca8e64 swift::ModuleFile::getType(llvm::PointerEmbeddedInt<unsigned int, 31>) + 1300
11 swift           0x0000000000ca902d swift::ModuleFile::getType(llvm::PointerEmbeddedInt<unsigned int, 31>) + 1757
12 swift           0x0000000000ca9281 swift::ModuleFile::getType(llvm::PointerEmbeddedInt<unsigned int, 31>) + 2353
13 swift           0x0000000000ca9294 swift::ModuleFile::getType(llvm::PointerEmbeddedInt<unsigned int, 31>) + 2372
14 swift           0x0000000000ca6bd0 swift::ModuleFile::getDecl(llvm::PointerEmbeddedInt<unsigned int, 31>, llvm::Optional<swift::DeclContext*>) + 29088
15 swift           0x0000000000cae9eb swift::ModuleFile::readMembers(llvm::SmallVectorImpl<swift::Decl*>&) + 251
16 swift           0x0000000000cb2a83 swift::ModuleFile::loadAllMembers(swift::Decl*, unsigned long) + 227
17 swift           0x000000000108fef6 swift::IterableDeclContext::loadAllMembers() const + 86
18 swift           0x000000000107f040 swift::NominalTypeDecl::getMembers() const + 16
19 swift           0x00000000010c3f30 swift::NominalTypeDecl::lookupDirect(swift::DeclName, bool) + 80
20 swift           0x00000000010c2a42 swift::DeclContext::lookupQualified(swift::Type, swift::DeclName, unsigned int, swift::LazyResolver*, llvm::SmallVectorImpl<swift::ValueDecl*>&) const + 3522
21 swift           0x0000000000ebf4c0
22 swift           0x0000000000ebf312 swift::TypeChecker::lookupMember(swift::DeclContext*, swift::Type, swift::DeclName, swift::OptionSet<swift::NameLookupFlags, unsigned int>) + 386
23 swift           0x0000000000f03802 swift::constraints::ConstraintSystem::lookupMember(swift::Type, swift::DeclName) + 290
24 swift           0x0000000000f69773 swift::constraints::ConstraintSystem::performMemberLookup(swift::constraints::ConstraintKind, swift::DeclName, swift::Type, swift::constraints::ConstraintLocator*, bool) + 2579
25 swift           0x0000000000f6b165 swift::constraints::ConstraintSystem::simplifyMemberConstraint(swift::constraints::Constraint const&) + 437
26 swift           0x0000000000f6c224 swift::constraints::ConstraintSystem::simplifyConstraint(swift::constraints::Constraint const&) + 68
27 swift           0x0000000000f04457 swift::constraints::ConstraintSystem::addConstraint(swift::constraints::Constraint*, bool, bool) + 23
28 swift           0x0000000000f4db75
29 swift           0x0000000000f56fb3
30 swift           0x0000000001023a48
31 swift           0x0000000001025a31
32 swift           0x0000000001023a88
33 swift           0x0000000001023f87
34 swift           0x0000000001023a2b
35 swift           0x0000000001025a31
36 swift           0x0000000001023a88
37 swift           0x0000000001020abe swift::Expr::walk(swift::ASTWalker&) + 46
38 swift           0x0000000000f4a178 swift::constraints::ConstraintSystem::generateConstraints(swift::Expr*) + 200
39 swift           0x0000000000e6e625 swift::TypeChecker::solveForExpression(swift::Expr*&, swift::DeclContext*, swift::Type, swift::FreeTypeVariableBinding, swift::ExprTypeCheckListener*, swift::constraints::ConstraintSystem&, llvm::SmallVectorImpl<swift::constraints::Solution>&, swift::OptionSet<swift::TypeCheckExprFlags, unsigned int>) + 245
40 swift           0x0000000000e74ae0 swift::TypeChecker::typeCheckExpression(swift::Expr*&, swift::DeclContext*, swift::Type, swift::ContextualTypePurpose, swift::OptionSet<swift::TypeCheckExprFlags, unsigned int>, swift::ExprTypeCheckListener*) + 576
41 swift           0x0000000000ee5570
42 swift           0x0000000000ee4be6 swift::TypeChecker::typeCheckTopLevelCodeDecl(swift::TopLevelCodeDecl*) + 134
43 swift           0x0000000000ea89ed swift::performTypeChecking(swift::SourceFile&, swift::TopLevelContext&, swift::OptionSet<swift::TypeCheckingFlags, unsigned int>, unsigned int) + 1117
44 swift           0x0000000000ce03bf swift::CompilerInstance::performSema() + 3295
45 swift           0x0000000000792819
46 swift           0x0000000000791943 frontend_main(llvm::ArrayRef<char const*>, char const*, void*) + 2643
47 swift           0x000000000078d0d7 main + 2567
48 libc.so.6       0x00007f2d81d78a40 __libc_start_main + 240
49 swift           0x000000000078ac79 _start + 41
Stack dump:
0.  Program arguments: /home/modocache/Downloads/swift-DEVELOPMENT-SNAPSHOT-2016-04-12-a-ubuntu15.10/usr/bin/swift -frontend -c -primary-file /home/modocache/Downloads/Swift-cfenv/Tests/LinuxMain.swift -target x86_64-unknown-linux-gnu -disable-objc-interop -I /home/modocache/Downloads/Swift-cfenv/.build/debug -g -emit-module-doc-path /tmp/LinuxMain-36e558.swiftdoc -module-name CFEnvironment -emit-module-path /tmp/LinuxMain-36e558.swiftmodule -o /tmp/LinuxMain-36e558.o 
1.  While type-checking expression at [/home/modocache/Downloads/Swift-cfenv/Tests/LinuxMain.swift:5:1 - line:7:2] RangeText="XCTMain([
    testCase(MainTests.allTests)
])"
2.  While loading members for 'MainTests' at <invalid loc>
3.  While deserializing 'verifyService' (FuncDecl #&#8203;7) 
4.  While deserializing decl #&#8203;21 (XREF)
5.  Cross-reference to module 'CFEnvironment'
    ... Service
<unknown>:0: error: unable to execute command: Aborted
<unknown>:0: error: compile command failed due to signal (use -v to see invocation)
<unknown>:0: error: build had 1 command failures
error: exit(1): /home/modocache/Downloads/swift-DEVELOPMENT-SNAPSHOT-2016-04-12-a-ubuntu15.10/usr/bin/swift-build-tool -f /home/modocache/Downloads/Swift-cfenv/.build/debug.yaml test

I've seen the "error deserializing an individual record" assertion before--you can read the entire discussion on the topic here. The conclusion was that "there is some limitation right now that everyone who wishes to use a module must also include all of its C header dependencies." So I wonder if this is a related issue? I see the sample project doesn't interact with C at all, though, so perhaps this is a red herring...

@swift-ci
Copy link
Contributor Author

Comment by Ricardo Olivieri (JIRA)

Thanks Brian for looking into this issue. In our Swift package there are no C dependencies; everything is implemented in pure Swift. Given that, I am thinking the cause for this error (at least in our case) is not related to modules and/or C header dependencies.

@modocache
Copy link
Mannequin

modocache mannequin commented Apr 17, 2016

I think it might be interesting to see if the same problem occurs when you don't use SwiftPM at all. Here's how you can compile a LinuxMain.swift file on its own:

swift $ utils/build-script -R --xctest
swift $ ~/GitHub/apple/build/Ninja-ReleaseAssert/swift-linux-x86_64/bin/swiftc \
    -Xlinker -rpath -Xlinker ~/GitHub/apple/build/Ninja-ReleaseAssert/xctest-linux-x86_64 \
    -L ~/GitHub/apple/build/Ninja-ReleaseAssert/xctest-linux-x86_64 \
    -I ~/GitHub/apple/build/Ninja-ReleaseAssert/xctest-linux-x86_64 \
    -Xlinker -rpath -Xlinker ~/GitHub/apple/build/Ninja-ReleaseAssert/foundation-linux-x86_64/Foundation \
    -L ~/GitHub/apple/build/Ninja-ReleaseAssert/foundation-linux-x86_64/Foundation \
    -I ~/GitHub/apple/build/Ninja-ReleaseAssert/foundation-linux-x86_64/Foundation \
    -I ~/GitHub/apple/build/Ninja-ReleaseAssert/foundation-linux-x86_64/Foundation/usr/lib/swift \
    LinuxMain.swift

However in your case you'd need to also compile and link CFEnvironment.swiftmodule when building the tests. But I think figuring this out could help isolate the problem--is it a problem in XCTest? The Swift compiler? SwiftPM?

@belkadan
Copy link

Ah, the backtrace looks like you have two modules named CFEnvironment: your main module and your test module. For now, try renaming your test module to something else—that's what's getting the compiler so confused.

@belkadan
Copy link

@mxcl: obviously people want to name their test modules the same as the module they're testing. Maybe the package manager should just tack "Tests" on the end when that happens?

@mxcl
Copy link
Contributor

mxcl commented Apr 18, 2016

SwiftPM appends “TestSuite” to test modules, so I guess the test module is not being identified as a test module.

@mxcl
Copy link
Contributor

mxcl commented Apr 18, 2016

> I had a bit of trouble building swiftpm on Linux using the latest commits on master

You need a newer swift-llbuild

@modocache
Copy link
Mannequin

modocache mannequin commented Apr 18, 2016

Ah dang, thanks--I thought I had updated my checkout but I guess not.

@swift-ci
Copy link
Contributor Author

Comment by Daniel Firsht (JIRA)

I'm working with r_olivieri (JIRA User) on this issue. I can confirm that changing the test module name does not make a difference.

I'm looking at the code that @modocache posted, I'm not sure that this is the best way to compile the test case outside SwiftPM. We should use the binaries and swiftmodules included in the snapshot. However, I'm not sure exactly how to do that without running `swift test`. I would appreciate it if someone can point me to what I need to include for that. We also would need to build the CFEnvironmentTestSuite.swiftmodule first.

@belkadan
Copy link

Somehow there are two things named CFEnvironment. The crash log above shows a command line with -module-name CFEnvironment and then separately the Cross-reference to module 'CFEnvironment', which implies that something already built depends on CFEnvironment.

@mxcl
Copy link
Contributor

mxcl commented Apr 18, 2016

Yes I agree.

Is it possible your have no subfolders in Tests/? Currently this is unsupported—though it should be,

@swift-ci
Copy link
Contributor Author

Comment by Daniel Firsht (JIRA)

Well it's structured pretty typically:

Swift-cfenv
   - Sources
      - CFEnvironment
         - Service.swift
   - Tests
      - LinuxMain.swift
      - CFEnvironment
         - MainTests.swift

I don't see anything wrong with this. Btw moving Service.swift to be directly under Sources doesn't have an effect either.

@swift-ci
Copy link
Contributor Author

Comment by Ricardo Olivieri (JIRA)

Hello @modocache,@mxcl - Just wondering if you guys have any updates regarding this defect. We have many test cases that used to execute just fine but are now failing when using the latest swift binaries (4/12) because of this defect. I guess the good news is that the problem is easily reproducible with the sample Swift package uploaded to this issue. 🙂

Is there any other information/details you would like from dfirsht (JIRA User) or me? As Daniel mentioned above, if you’d like us to build/compile the test case plus the module being tested without using SPM, we would need details/instructions on how to do that. We could not figure out how to accomplish this from what Brian pasted above in a previous message.

Thanks!

@swift-ci
Copy link
Contributor Author

Comment by Ricardo Olivieri (JIRA)

Hello @modocache, @mxcl - Do you guys think this issue may get resolved before the next drop of the Swift 3 development binaries? This issue is currently blocking several of our projects. We are not aware of any work-arounds. Thanks.

@modocache
Copy link
Mannequin

modocache mannequin commented Apr 25, 2016

Dang, sorry for not being super responsive. I don't have a great idea of what to do, although my thought is that this has more to do with SwiftPM than XCTest itself. Maybe @aciidb0mb3r or czechboy0 (JIRA User) have some theories as to what's going on here, or how to work around it?

@ankitspd
Copy link
Member

This should be fixed by #282
The problem is swiftc infers the module-name for executable it generates as the output file name which turns out to be CFEnviornment.xctest which was colliding.

@ankitspd
Copy link
Member

r_olivieri (JIRA User) Not sure when the next toolchain will be released but the fix is very trivial (see PR -> #282 you can build swiftpm yourself with this change and use until this is merged.

@ankitspd
Copy link
Member

A short term (less than ideal) hack would be running `swift build` then editing .build/debug.yaml and replacing the instances of `CFEnviornment.xctest` with `CFEnviornmentTest.xctest` then run `swift test` but it'll be overwritten again once you run `swift build` again...

@swift-ci
Copy link
Contributor Author

Comment by Honza Dvorsky (JIRA)

I can confirm that the renaming of *.xctest to *Tests.xctest in debug.yaml works as a workaround (at least until swift build is ran again). Obviously we need #282 to be merged ASAP and hopefully it won't be another two weeks for another snapshot, because we just missed the release yesterday 🙁

I also have multiple projects' tests broken by this issue.

@ankitspd
Copy link
Member

czechboy0 (JIRA User) You can build swiftpm yourself and replace toolchain version with self built version.

@swift-ci
Copy link
Contributor Author

Comment by Ricardo Olivieri (JIRA)

Thanks @modocache, @aciidb0mb3r for your help. I can also confirm that editing .build/debug.yaml by replacing `*.xctest` with `*Test.xctest` fixes the problem. We look forward to the next release of the Swift 3 binaries. Building swiftpm ourselves is not quite an option for us (we'd need to host and distribute it to all stakeholders and modify our CI pipeline among other changes). It is good to know that this problem will be fixed in the next drop of the binaries. Thanks!

@swift-ci
Copy link
Contributor Author

Comment by Ricardo Olivieri (JIRA)

There's a new drop of the binaries (April 25th). Hopefully the fix is there. We will give it a try!

@swift-ci
Copy link
Contributor Author

Comment by Ricardo Olivieri (JIRA)

Looks like that pull request (#282 has not been merged yet... which would mean that the Swift 3 April 25th binaries do not have this fix.

@ddunbar
Copy link
Member

ddunbar commented Apr 28, 2016

Apologies for not getting this merged sooner, I saw the PR but didn't understand how critical it was... looking now.

@mxcl
Copy link
Contributor

mxcl commented Apr 28, 2016

Merged.

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

No branches or pull requests

5 participants