- add a default implementation of MutableCollection’s
subscript(bounds: Range<_>) with the most general signature possible
- it is marked unavailable in order to prevent the
infinite recursion bug reported in SR-14848
- add a conditionally-available subscript(bounds: Range<_>) -> Slice<Self>
only when Subsequence is Slice<Self>. This will supersede
the unconditional extension that provides the same signature.
* Not implementing POSIXError for a given platform is not a blocking
problem to getting a successful build of Swift. However, it is
part of the validation tests (albeit locked behind REQUIRES) and is
referenced when building Foundation. Implement by forklifting from
`sys/errno.h`.
* Some Foundation class implementations require some missing includes in
the platform modulemap. Add these.
- adds a default implementation of Collection’s subscript(bounds: Range<_>)
with the most general signature possible
- it is marked unavailable in order to prevent the
infinite recursion bug reported in SR-14848
- Collections whose SubSequence is Slice<Self> still get the proper default, as intended.
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.
COW checking needs that all libraries are consistently compiled with asserts enabled. This is not the case for the Foundation overlay anymore.
Therefore it does not work with some tests which interop with Foundation.
The solution here is to disable COW checking by default, but enable it for Array tests which do not interop with Foundation.
* move all ObjC array tests into a separate file ArraysObjc.swift.gyb
* merge the remaining Arrays.swift.gyb and ArrayNew.swift.gyb files
* move the utilities from ArrayTypesAndHelpers.swift into its only use into ArraysObjc.swift.gyb
The actual XCTest overlay has not been maintained in this repository for years. (It is distributed in Xcode (libXCTestSwiftSupport.dylib), along with XCTest.framework itself.)
The code we have here is badly out of date, and the fact that we have it on the module path in CI makes it interfere with the contents of recent SDKs.
Remove the XCTest overlay from this repository; pick it up from the SDK instead.
rdar://76915582
Commit the platform definition and build script work necessary to
cross-compile for arm64_32.
arm64_32 is a variant of AARCH64 that supports an ILP32 architecture.
* [Diagnostics] Use DeclDescriptiveKind on data flow diagnostics to improve diagnostic message
* [tests] Add regression tests to SILOptimizer/return.swift
* [tests] Adapt other tests to changes of SR-14505
* [Diagnostics] Adapt message for missing return diagnostics, remove article
* [Diagnostics] Adapt message for missing return diagnostics to have a note with fix
* [tests] Adjust tests in validation suit
* [stdlib][SR-13883] Avoid advancing past representable bounds when striding.
* [stdlib] Expand a test and add a comment to ensure correct floating-point stride bounds checking.
* [stdlib][NFC] Clarify a comment in a test.
* [stdlib][NFC] Adjust copyright notices, clarify comments, delete '-swift-version=3' for tests.
* [stdlib] Add implementations for fixed-width integer strides for performance.
* [stdlib] Document `Strideable._step` and modify overflow checking behavior of `Stride*Iterator`.
* [stdlib] Address reviewer comments, postpone documentation changes
* [stdlib][NFC] Update documentation for '_step(after:from:by:)'
* [stdlib][NFC] Use 'nil' instead of an arbitrary value for integer striding '_step' index
Specifically, given code like the following:
```
(%1, %2) = multi_result_inst %0 (a)
inst_to_delete %1 (b)
inst_to_delete %2 (c)
```
We would sometimes visit (c) before (b). So if nextII was (b) at that point, we
would think that we were safe. Then we process (b), move nextII from (b) ->
(c). Then we delete both (b) and (c). =><=.
The solution to this is each iteration of the delete loop, we track /all/
instructions that eliminateDeadInstruction is going to eliminate and ensure that
after each callback is called we have moved past all visited instructions (even
ones we visited previously). This is done using a small set that I clear each
iteration.
I also re-enabled the dictionary test that exposed this issue when testing
-O/-Osize.
rdar://71933996
Here we fix a few portability issues affecting running the validation tests on OpenBSD. The remaining failures will be dealt with separately.
1. In the `rth` tool, ensure `-z origin` is specified to the linker when
using `$ORIGIN`, as required on this platform.
2. Explicitly set the rpath in the `dsohandle-multi-module` execution
test, since the test uses built dynamic libraries during the test.
3. Erase the environment variable instead of using `env -u`, the latter
of which is not portable.
On Linux with -O:
[ RUN ] Set.formSymmetricDifference
stdout>>> check failed at /Users/docker_user/src/build/buildbot_linux/swift-linux-x86_64/main.swift, line 3245
stdout>>> unexpected value: "94788628116752" (of type Swift.Int)
[ FAIL ] Set.formSymmetricDifference
The test is roughly:
var s1 = Set(...)
let s1_copy = s1
let identity1 = s1._rawIdentifier()
s1.someMutatingMethod1()
check(s1)
check(s1_copy)
s1.someMutatingMethod2()
// Mutating the set should cause an identity change
releaseAssert(identity1 != s1._rawIdentifier())
On Linux, the optimizer is able to destroy s1_copy before the call to
s1.someMutatingMethod2(), which generates new Set storage. This new
storage uses the same address as the destroyed s1_copy.
Fixes rdar://72933150 ([CanonicalOSSA] Fix Set.swift unit test that assumes object lifetime)
Unchecked APIs must still perform checks in debug builds to ensure that invariants aren’t violated.
(I.e., these aren’t a license to perform invalid operations — they just let us get rid of the checks when we know for sure they are unnecessary.)
Due to a couple of unfortunate circumstances, appending an NSArray instance to an Array instance does not actually append any elements.
The cause is https://github.com/apple/swift/pull/29220, which accidentally optimized away the actual loop that appends the elements in this particular case. (And only this particular case, which is why this wasn’t detected by the test suite.)
When the argument to `Array.append(contentsOf:)` is of type NSArray, the `newElements is [Element]` expression is compiled into a runtime check that returns true, eliminating the subsequent loop over the remaining items of the iterator. Sadly, NSArray.underestimatedCount` currently returns 0, so the earlier _copyContents call is a noop, so no elements get added to `self` at all.
Turning the `is` test into a direct equality check between the metatype instances resolves the issue.
We can't actually check for NaN (because the notion doesn't exist for Comparable), but we can require that the endpoint is non-exceptional by checking if it equals itself.
