This is a wild guess at what might be causing our persistent, random
String failures on the main branch:
```
Swift(macosx-x86_64) :: Prototypes/CollectionTransformers.swift
Swift(macosx-x86_64) :: stdlib/NSSlowString.swift
Swift(macosx-x86_64) :: stdlib/NSStringAPI.swift
Swift(macosx-x86_64) :: stdlib/StringIndex.swift
Swift-validation(macosx-x86_64) :: stdlib/String.swift
Swift-validation(macosx-x86_64) :: stdlib/StringBreadcrumbs.swift
Swift-validation(macosx-x86_64) :: stdlib/StringUTF8.swift
```
FWIW, it appears this is *not* caused by https://github.com/apple/swift/pull/62717:
that change has also landed on release/5.8, and I haven’t seen these
issues on that branch.
Our atomic breadcrumbs initialization vs its non-atomic loading
gives me an uneasy feeling that this may in fact be a long standing
synchronization issue that is only now causing problems (for whatever
reason). I am unable to reproduce these issues locally, so this guess
may be (and probably is) wildly off the mark, but this PR is likely
to be a good idea anyway, if only to rule out this possibility.
rdar://104751936
Based on its argument names and messages, `expectEqual` and friends expects the expected value of the calculation being tested to be provided as its first argument, and the actual value as the second:
```
expectEqual(4, 2 + 2)
```
This does not always match actual use -- folks like myself find the opposite ordering far more natural:
```
expectEqual(2 + 2, 4)
```
`expectEqual` currently uses the `expected`/`actual` terminology in its failure messages, causing confusion and needless suffering.
Change `expectEqual`'s declaration and error messages to use a naming scheme that does not assume specific roles for the two arguments. (Namely, use `first`/`second` instead of `expected`/`actual`.)
An alternative way to solve this would be to use argument labels, as in `expectEqual(expected: 4, actual: 2 + 2)`, or to introduce some sort of expression builder scheme such as `expect(2 + 2).toEqual(2)`. These seem needlessly fussy and overly clever, respectively.
We need to run utils/swift-darwin-postprocess.py on every executable test on Darwin platforms to work around a dyld issue. (And to ad-hoc sign executables on platforms that need it.)
Add a %target-codesign step to stress tests that are currently missing it.
The mutating collection subscript for discontiguous slices assigns to the wrong group
of indices. This fixes the behavior and adds test coverage.
rdar://problem/70690643
In debug configurations, fatal error messages include file & line number information. This update presents this information in a format matching the diagnostic conventions used by the compiler, which can be a slight productivity boost.
Code compiled with optimizations enabled (which is most production code) does not output this information, so it isn’t affected by this change.
Original format:
Fatal error: A suffusion of yellow: file calc.swift, line 5
New format:
calc.swift:5: Fatal error: A suffusion of yellow
Resolves rdar://68484891
Clean up a few general patterns that are now obviated by canImport
This aligns more generally with the cleanup that the Swift Package
Manager has already done in their automated XCTest-plumbing tool in
apple/swift-package-manager#1826.
It is possible that the rest of the platforms are relying in some not
clearly documented behaviour that the stdout is flushed before stderr
can be used, or something similar. Windows didn't seem to like that, and
was sometimes outputting the stderr messages interlaced with the stdout
messages (specially in the Azure testing for VS2017). The initial
solution was adding -DAG to some CHECK lines, but that doesn't cover all
the possibilities, and wasn't enabled for all the checks.
I tried to fix it in several ways, but none of them were perfect, and
many of them were deadlocking. There's a fundamental difference between
others and Windows and that is that for others stdout seems to have a
little bit of an edge in being treated first. I tried to get the Windows
code closer to that idea, but I have no luck. Some of the approaches
were using the main thread to read from the threads reading stdout and
stderr; using only the main thread and IOCP on the pipes reading from
the child process; and flushing after every output to stdout. None of
them were perfect.
The final solution is a hack, but it seems to not fail when I run the
test repeatedly in my machine, while other approaches were failing at
least once before I discarded them. The solution is including a small
sleep (1 millisecond) in the Windows code. This should yield the
execution time slice to other thread/process, which seems to do the
trick and keep the stdout before the stderr.
Hopefully this fixes the errors in Azure, and doesn't affect the rest of
the testing machines. Being a really small sleep also should not affect
the duration of the test itself.
This adjusts the paths in the test to support the Linux and Windows path
separators. Loosen the test to accept the interleaved stdout output on
Windows.
Android is one of those platforms that define the symbol EOF as a
negative number. Trying to turn it into an UInt8 will only crash the
test. Move the transformation after we have checked for EOF first. In my
opinion, in other platforms, having the EOF attached to the getline
result was also invalid, and that's probably why the two test that use
EOF were sending an extra newline.
Even with this, the tests do not pass on Android because it deadlocks
waiting for input/output from the child process, which never happens. I
haven't find why this happens, but only happens if the last test of the
suite closes stdin. I will try to fix that in another PR.
When testing runtime lookup changes, we want to make sure each test runs in isolation. Add a new modifier, `.requireOwnProcess()`, to enable tests to guarantee they’re run in isolation.
Different tests used different os checks for importing Darwin, Glibc and
MSVCRT. This commit use the same pattern for importing those libraries,
in order to avoid the #else branches of the incorrect patterns to be
applied to the wrong platform. This was very normal for Android, which
normally should follow the Linux branches, but sometimes was trying to
import Darwin or not importing anything.
The standarized pattern imports Darwin for macOS, iOS, tvOS and watchOS.
It imports Glibc for Linux, FreeBSD, PS4, Android, Cygwin and Haiku; and
imports MSVCRT for Windows. If a new platform is introduced, the else
branch will report an error, so the new platform can be added to one of
the branches (or maybe add a new specific branch).
In some cases the standard pattern was modified because some test required
it (importing extra modules, or extra type aliases), and in some other
cases some branches were removed because the test will not have used
them (but it is not exhaustive, so there might be some unnecessary
branches).
This should, at least, fix three tests for Android (the three
dynamic_replacement*.swift ones).
Stress tests are, by definition, stressful. They intentionally burn a
lot of resources by using randomness to hopefully surface state machine
bugs. Additionally, many stress tests are multi-threaded these days and
they may attempt to use all of the available CPUs to better uncover
bugs. In isolation, this is not a problem, but the test suite as a whole
assumes that individual tests are single threaded and therefore running
multiple stress tests at once can quickly spiral out of control.
This change formalizes stress tests and then treats them like long
tests, i.e. tested via 'check-swift-all' and otherwise opt-in.
Finally, with this change, the CI build bots might need to change if
they are still only testing 'validation' instead of all of the tests.
I see three options:
1) Run all of the tests. -- There are very few long tests left these
days, and the additional costs seems small relative to the cost of
the whole validation test suite before this change.
2) Continue checking 'validation', now sans stress tests.
3) Check 'validation', *then* the stress tests. If the former doesn't
pass, then there is no point in the latter, and by running the stress
tests separately, they stand a better chance of uncovering bugs and
not overwhelming build bot resources.
* Unify the capitalization across all user-visible error messages (fatal errors, assertion failures, precondition failures) produced by the runtime, standard library and the compiler.
* Update some more tests to the new expectations.
- CYGWIN symbol is used to distinguish Cygwin environment from other OS
and other environment in Windows.
- Added windows and windowsCygnus to OSVersion in StdlibUnittest
[test] Add a timeout to runRaceTest(). Use it to limit test AtomicInt.swift.
This cuts AtomicInt.swift's execution time from several hours to
about ten minutes on slow hardware and slow build configurations.
The new names are what people generally expect. The old names made more
sense in the old times when the 'Optional.None' case could not be
created with the 'nil' keyword.
As part of the extensive work on value types in Foundation this year, we
decided to also add value types for these three key classes. In addition
to adding value semantics, the API was extensively audited to improve
Swift interop (especially Calendar).
rdar://26628184
This reverts commit 46a9f57329.
This broke Swift CI, OSS incremental RA:
./swift/stdlib/public/SDK/Foundation/TimeZone.swift:228:45: error: 'NSTimeZone' is not implicitly convertible to 'TimeZone'; did you mean to use 'as' to explicitly convert?
return lhs._wrapped.isEqual(to: rhs._wrapped)
As part of the extensive work on value types in Foundation this year, we
decided to also add value types for these three key classes. In addition
to adding value semantics, the API was extensively audited to improve
Swift interop (especially Calendar).
rdar://26628184
This reverts commit 9c1f21bdf0.
This breaks swift-ci for everyone:
stdlib/public/SDK/Foundation/Calendar.swift:426:74: error: 'DateInterval' is only available on iOS 10.0 or newer
public func dateInterval(of component: Component, for date: Date) -> DateInterval? {
