Misaligned indices were fixed in 5.1, but we should disable the test
when testing back deployment.
Adds a shared helper to StdlibUnittest for the run time check.
Under non-editor mode, the fixit for inserting protocol stubs is associated with a note
pointing to the missing protocol member declaration which could stay in a separate file from
the conforming type, leading to the behavior of rdar://51534405. This change checks if
the fixit is in a separate file and issues another note to carry the fixit if so.
rdar://51534405
FlattenCollection.swift.gyb and LazyFilterCollection.swift.gyb tests are taking 1000+ seconds to execute, even with optimizations. It should be possible to shorten these, but meanwhile, mark them as long tests so speed up regular testing.
rdar://problem/52872766
rdar://problem/52873170
Fixes a general category (pun intended) of scalar-alignment bugs
surrounding exchanging non-scalar-aligned indices between views and
for slicing.
SE-0180 unifies the Index type of String and all its views and allows
non-scalar-aligned indices to be used across views. In order to
guarantee behavior, we often have to check and perform scalar
alignment. To speed up these checks, we allocate a bit denoting
known-to-be-aligned, so that the alignment check can skip the
load. The below shows what views need to check for alignment before
they can operate, and whether the indices they produce are aligned.
┌───────────────╥────────────────────┬──────────────────────────┐
│ View ║ Requires Alignment │ Produces Aligned Indices │
╞═══════════════╬════════════════════╪══════════════════════════╡
│ Native UTF8 ║ no │ no │
├───────────────╫────────────────────┼──────────────────────────┤
│ Native UTF16 ║ yes │ no │
╞═══════════════╬════════════════════╪══════════════════════════╡
│ Foreign UTF8 ║ yes │ no │
├───────────────╫────────────────────┼──────────────────────────┤
│ Foreign UTF16 ║ no │ no │
╞═══════════════╬════════════════════╪══════════════════════════╡
│ UnicodeScalar ║ yes │ yes │
├───────────────╫────────────────────┼──────────────────────────┤
│ Character ║ yes │ yes │
└───────────────╨────────────────────┴──────────────────────────┘
The "requires alignment" applies to any operation taking a
String.Index that's not defined entirely in terms of other operations
taking a String.Index. These include:
* index(after:)
* index(before:)
* subscript
* distance(from:to:) (since `to` is compared against directly)
* UTF16View._nativeGetOffset(for:)
We are now seeing another one crash in CI. Best guess is that the first
one of these tests to run can randomly crash - perhaps an initialization
isssue.
The C library functions used here do not appear without the C runtime
being imported (ucrt or MSVCRT). Adjust the test as such. This exposes
a stack corruption in the test which needs to be resolved.
Split up the commands into multiple RUN lines. Use a temporary to
actually capture the output of multiple invocations to compose them into
a single stream.
Replace the `export` usage with `env` which the lit interpreter is able
to process even on Windows.
This makes HashingRandomization pass on Windows.
The embedded shell script in the RUN command for lit is problematic for
non-sh shell environments (i.e. Windows). This adjusts the tests to
uniformly build the code for the ObjC runtime. However, the Objective-C
code is only built under the same circumstances that it is currently
enabled - the availability of the needed frameworks. The empty object
on other runtimes will have no material impact. The swift side of it
checks whether the runtime is built with ObjC interop. This allows us
to largely use the same command line for all the targets. The last
missing piece is that the `-fobjc-runtime` requires that we run a modern
ObjC runtime. We enable this unconditionally in lit for the non-Apple
targets.
This improves the validation test coverage for the standard library on
Windows.
With the option -Xllvm -basic-dynamic-replacement the runtime functions are not called (so it works with an old swift library).
But calling the original of a replaced function is not supported in this case.
Some tests are limited to only Linux, when they should also pass for
Android.
Additionally, InputStream.swift.gyb was disabled for Android ARMv7, but
wasn't for Android AArch64, which allow me to find the error on it and
fix it on #24521.
Finally, StringLowercasedUppercased is interesting in Android because it
checks the used ICU is correct for performing the tasks that the stdlib
needs.
The REQUIRES written one in each line were impossible to satisfy in any
platform, so the test wasn't running at all. This was changed to a
REQUIRE-ANY listing all the platforms (and adding Android). I also
needed to add runAllTest() at the end to make the test pass.
Until the issue is fixed. Tracked by:
<rdar://problem/49791522> Swift CI Test failures: IRGen/autorelease_optimized_armv7/aarch64.
https://bugs.swift.org/browse/SR-10474
The initializer was originally introduced without proper availability; in https://github.com/apple/swift/pull/23643, we fixed this by applying the `@_alwaysEmitIntoClient` attribute. However, this had the unfortunate side-effect that the symbol disappeared from `libswiftCore.dylib`, which somehow confuses some simulator builds.
Try to figure out what’s happening by replacing the third closure argument with an integer return value. This changes the mangled name of the bulk initializer, which should make it more obvious how/why these builds fail.
rdar://problem/49479386
As of 14d89ec1c1, these tests now take
2.25x longer than the *entire* validation test suite on fast machines.
Mark them as "long_test" for now until they can be broken into smaller
concurrent tests.
Fix several problems with FixedPointConversion generation code.
The first problem is that at some point `repr(value)` was being used,
which turn the number into a string. That was great for printing the
number, but make the test against the value of the number (like
`testValue < otherMin` always false. There were a number of tests that
were never performed, specifically the integer tests.
The second problem was using doubles in the Python code. For Float32 and
Float64 the tests were generated correctly, but in the case of Float80,
the test adding or removing a quantity to the maximum/minimum were
failing because of the lack of precission (Adding 0.1 to a very
big/small number is the same as not adding anything). Switching to
Decimal should keep enough precission for the tests.
Finally the last problem was that the bounds of the conversions are not
actually `selfMin` and `selfMax`, but the values returned by the utility
function `getFtoIBounds`. For example for unsigned types, the lower
bound is always -1, not zero (every value between -1 and zero is rounded
to zero, and doesn't fail).
Instead of using nested gyb templates, use lit.cfg %target-ptrsize,
which should be faster, cleaner, and provides correct line-directive
output.
Remove a bunch of warnings in Swift when compiling the generated result
of FixedPointConversion.swift.gyb.
Co-authored-by: Gwynne Raskind <gwynne@users.noreply.github.com>
