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.
This improves 'ninja check-swift-validation' performance by about 2.9x
on my Linux desktop. Also, move them to validation-test where the other
long tests live.
Even without ASAN this failes with "corrupted double-linked list".
<rdar://problem/35797159> [Associated Type Inference] Swift CI: 1. OSS - Swift ASAN - Ubuntu 16.04 (master) heap-use-after-free ASTContext::getSpecializedConformance llvm::FoldingSetBase::InsertNode
Waiting for a fix for <rdar://35797159> [Associated Type Inference]
Swift CI: 1. OSS - Swift ASAN - Ubuntu 16.04 (master)
heap-use-after-free ASTContext::getSpecializedConformance
llvm::FoldingSetBase::InsertNode
If a type has the same layout as one of the basic integer types, or has a single refcounted pointer representation, we can use prefab value witness tables from the runtime instead of instantiating new ones. This saves quite a bit of code size, particularly in the Apple SDK overlays, where there are lots of swift_newtype wrappers and option set structs.
Beyond switching hashing algorithms, this also enables per-execution hash seeds, fulfilling a long-standing prophecy in Hashable’s documentation.
To reduce the possibility of random test failures, StdlibUnittest’s TestSuite overrides the random hash seed on initialization.
rdar://problem/24109692
rdar://problem/35052153
Introduce _Hasher, representing an opaque hash compression function.
Add the method _hash(into:) as a Hashable requirement, decoupling the choice of hash function from Hashable's implementation. The default implementation of _hash(into:) has a default implementation that simply feeds hashValue to the hasher.
Add _hash(into:) implementations for the default integer types. Note that Int.hashValue does not return self anymore.
Add struct _LegacyHasher, emulating Swift 4.1 hashes in the new interface.
Restore (un-revert) sting comparison, with fixes
More exhaustive testing of opaque strings, which consistently reproduces prior sporadic failure. Shims fixups. Some test tweaking.
* Make Range conditionally a Collection
* Convert ClosedRange to conditionally a collection
* De-gyb Range/ClosedRange, refactoring some methods.
* Remove use of Countable{Closed}Range from stdlib
* Remove Countable use from Foundation
* Fix test errors and warnings resulting from Range/CountableRange collapse
* fix prespecialize test for new mangling
* Update CoreAudio use of CountableRange
* Update SwiftSyntax use of CountableRange
* Restore ClosedRange.Index: Hashable conformance
* Move fixed typechecker slowness test for array-of-ranges from slow to fast, yay
* Apply Doug's patch to loosen test to just check for error
* Remove RegisterPreservingCC. It was unused.
* Remove DefaultCC from the runtime. The distinction between C_CC and DefaultCC
was unused and inconsistently applied. Separate C_CC and DefaultCC are
still present in the compiler.
* Remove function pointer indirection from runtime functions except those
that are used by Instruments. The remaining Instruments interface is
expected to change later due to function pointer liability.
* Remove swift_rt_ wrappers. Function pointers are an ABI liability that we
don't want, and there are better ways to get nonlazy binding if we need it.
The fully custom wrappers were only needed for RegisterPreservingCC and
for optimizing the Instruments function pointers.
Include the initial implementation of _StringGuts, a 2-word
replacement for _LegacyStringCore. 64-bit Darwin supported, 32-bit and
Linux support in subsequent commits.
In grand LLVM tradition, the first step to redesigning _StringCore is
to first rename it to _LegacyStringCore. Subsequent commits will
introduce the replacement, and eventually all uses of the old one will
be moved to the new one.
NFC.
NSString has a stricter concept of equality than Swift’s String, so it is possible to construct NSDictionary/NSSet instances that contain duplicate keys according to Swift’s definition of string equality. This change improves how we handle these cases by coalescing the duplicate keys (keeping a single value).
rdar://problem/35995647
* Remove a bunch of Default(Bidirectional|RandomAccess)Indices usage from stdlib and test
* Remove some DefaultRandomAccessIndices and IndexDistance usage from Foundation
* Remove no-longer-used internal type in Existentials.swift
* Get rid of indicesForTraversal
