-
Notifications
You must be signed in to change notification settings - Fork 52
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
Resolve some test issues #71
Conversation
@swift-ci test |
90cc63c
to
12cc95b
Compare
@swift-ci test |
12cc95b
to
45772d9
Compare
@swift-ci test |
The original autogenerated swift file is so humongous that it causes problems for some folks. Split it up into one file per XCTestCase.
@swift-ci test |
@swift-ci test |
Compiling this one file probably needed too much memory for the CI machines, and so they started thrashing, leading to 10x slower build times than expected. This also explains the off hand comments I sometimes saw about not being able to build tests at all on constrained machines -- sadly I can't recall any actual bug reports about that, so it remained undiagnosed. |
this whole time i thought the problem was vague type inference… i did not know source file length could have such an impact on typechecker performance… |
I suspect it's all about the sheer amount of memory that the compiler needed to hold the whole thing all at once. This also explains why I never really saw this in my local builds -- I don't typically try building things on memory-constrained systems. |
Disable test registration outside of CMake builds.
This will allow this code base to be built with build systems other than CMake and SPM without these test manifests suddenly appearing again.
Split Basics.swift.gyb into 26 different files, one for each test case.
The original autogenerated swift file is so humongous that it causes problems for some folks.
Fix CMake configuration for package tests.
Checklist