Rewrite part of file with StdlibUnittest

[frootloops]

No description provided.

[gottesmm]

Is it possible for you to also split up this file into tests for different sorts of printing (i.e. one for Array, one for Integer, one for Floating Point)?

Very long stdlib unittest tests are very difficult to debug when we run into optimizer issues and splitting it into smaller files would make it easier to bisect/debug.

[frootloops]

@gottesmm Yes, It's possible. Do you want to see it in one big PR or in a few small PRs?

[gottesmm]

I would suggest a few small PRs. It will make it easier to localize/fix/revert commits if issues come up.

[frootloops]

@gottesmm Ok. So is this PR ready to merge? :)

[gottesmm]

I actually think I need someone on the stdlib team to review it. (I was going to review it myself, but I am not a stdlib engineer). I am going to send it to Dmitri.

[frootloops]

@gottesmm thanks. I will continue to work on this file

[frootloops]

@gottesmm Should I create test/1_stdlib/Print folder or just create files in test/1_stdlib/ folder (test/1_stdlib/PrintArray.swif, test/1_stdlib/PrintDictionary.swif etc) when I will split this big file into small files?

[gottesmm]

I am not sure TBH. I would leave that up to @gribozavr.

That being said, I imagine that if you put the tests in the Print folder, it will be ok to call the tests Print*.swift. So why not just do it in test/1_stdlib and if Dmitri wants us to create a folder, then we can move the tests to that directory in a subsequent commit. That would make it easier in terms of munging patches.

[gribozavr]

@frootloops Thanks! Two comments:

1. You need to call runAllTests(), or none of the new tests would be run.
2. Because StdlibUnittest forks a new process, I don't think the command line argument would be passed down to it. I think the way to do it would be to change the _ParentProcess._spawnChild() method to also forward other command line arguments. You'd need to add a test for that in a new file, validation-test/stdlib/StdlibUnittestCommandLineArguments.swift.

[frootloops]

@gribozavr I'm still working on this PR but if you can please have a look at the PR and leave any comments.

I have a few questions:

1. I have a lot of copies StructPrintable, LargeStructPrintable and others. How can I share these structs and classes between test files or maybe it's ok.
2. Should I put // XFAIL: linux in every new Print* files?
3. Should I put setlocale(LC_ALL, arg) stuff in every new Print* files?
4. What is the difference between RUN: %target-run and RUN: %target-run-simple-swift?

Thanks

[frootloops]

@gribozavr when you will have time please have a look :)

[frootloops]

Testing Time: 1415.60s
  Expected Passes    : 7668
  Expected Failures  : 8
  Unsupported Tests  : 39
-- check-swift-all-macosx-x86_64 finished --
--- Finished tests for swift ---

[gribozavr]

@frootloops Thank you!

1. I have a lot of copies StructPrintable, LargeStructPrintable and others. How can I share these structs and classes between test files or maybe it's ok.

Swift can share code with modules. You can put common definitions into, say, test/1_stdlib/Inputs/PrintTestTypes.swift, and build modules out of it in every test that needs these types.

1. Should I put // XFAIL: linux in every new Print* files?

Only if it fails on Linux. Let me know if I need to run these for you.

1. Should I put setlocale(LC_ALL, arg) stuff in every new Print* files?

Strictly speaking, only floating point tests need it. We know from the implementation that other behavior is implemented without relying on locales.

1. What is the difference between RUN: %target-run and RUN: %target-run-simple-swift?

docs/Testing.rst:

• %target-run: run a command on the target machine.
• %target-run-simple-swift: build a one-file Swift program and run it on the target machine.

So, the latter builds the binary for you, while for the former you need to build it yourself using another RUN line.

[gribozavr]

I don't think anything depends on Darwin here.

[gribozavr]

@frootloops Please try to prune import Darwin from the smaller files, most of them don't need it as far as I see. This will allow the tests to pass on Linux.

[frootloops]

@gribozavr have a look at the PR. I updated it and if you can please run a test suite on a linux machine.

[frootloops]

@gribozavr You were right about locale. Can you run tests on linux again?
And look at stdlib/private/StdlibUnittest/StdlibUnittest.swift.gyb because maybe I miss something

[gribozavr]

This should be modeled as a setup block.

[frootloops]

@gribozavr thanks for comments. I updated the PR

[gribozavr]

@frootloops Thank you, merged!