Skip to content

Conversation

@al45tair
Copy link
Contributor

If the threading package is set to "none", don't actually use threads in the unit tests.

rdar://95011060

@al45tair
Copy link
Contributor Author

This should fix the failure we saw in #59365

…ds mode.

If the threading package is set to "none", don't actually use threads in the
unit tests.

rdar://95011060
@al45tair
Copy link
Contributor Author

@swift-ci Please smoke test

@al45tair
Copy link
Contributor Author

preset=buildbot_incremental_linux_crosscompile_wasm
@swift-ci Please test with preset Linux Platform

@kateinoigakukun
Copy link
Member

kateinoigakukun commented Jun 14, 2022

[ RUN      ] LazyUnsafeMutexTest.TryLockable
/home/build-user/swift/unittests/Threading/LockingHelpers.h:39: Failure
Value of: ret
  Actual: true
Expected: false

Hmm, should we keep the behavior cannot lock a locked lock in no thread impl? Or skip those tests?

@al45tair
Copy link
Contributor Author

I think we should skip those tests. It seems pointless tracking the fact that we've "locked" a lock in an un-threaded environment. Looks like I also need to turn off the ExclusiveAccess tests when threading is set to none.

@al45tair
Copy link
Contributor Author

al45tair commented Jul 7, 2022

Closed in favour of #59561 (which also disables a few tests for the threading=none case).

@al45tair al45tair closed this Jul 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants