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>
String.Index has an encodedOffset-based initializer and computed
property that exists for serialization purposes. It was documented as
UTF-16 in the SE proposal introducing it, which was String's
underlying encoding at the time, but the dream of String even then was
to abstract away whatever encoding happend to be used.
Serialization needs an explicit encoding for serialized indices to
make sense: the offsets need to align with the view. With String
utilizing UTF-8 encoding for native contents in Swift 5, serialization
isn't necessarily the most efficient in UTF-16.
Furthermore, the majority of usage of encodedOffset in the wild is
buggy and operates under the assumption that a UTF-16 code unit was a
Swift Character, which isn't even valid if the String is known to be
all-ASCII (because CR-LF).
This change introduces a pair of semantics-preserving alternatives to
encodedOffset that explicitly call out the UTF-16 assumption. These
serve as a gentle off-ramp for current mis-uses of encodedOffset.
This fix updates various initializers to handle incoming empty buffers
that happen to have a nil base. They should simply create another
buffer with nil base rather than crashing!
It is valid for an Unsafe[Raw]BufferPointer can have a nil base
address. This allows round-tripping with C code that takes a
pointer/length pair and uses `0` as the pointer value.
The original design wrongly assumed that we would use a sentinel value
for empty buffers and was never updated for or tested with the current
design.
Fixes <rdar://problem/47946984> Regression in Foundation.Data's
UnsafeBufferPointer constructor.
