Escapingness is a property of the type of a value, not a property of a function
parameter. Having it as a separate parameter flag just meant one more piece of
state that could get out of sync and cause weird problems.
Instead, always look at the noescape bit in a function type as the canonical
source of truth.
This does mean that '@escaping' is now printed in a few diagnostics where it was
not printed before; we can investigate these as separate issues, but it is
correct to print it there because the function types in question are, in fact,
escaping.
Fixes <https://bugs.swift.org/browse/SR-10256>, <rdar://problem/49522774>.
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
We set the type of ParamDecls when applying solutions in the normal path, but
sometimes code completion will type check an expression inside a closure without
checking the outer expression. In this case, we may have inferred a type for
the ParamDecl, but we don't write it back.
Instead, just look at the DeclRefExpr's type.
Fixes <rdar://problem/42098113>.
This is a defensive move to avoid duplicated work and guard against crashes
when a multi-expression closure body or TapExpr has not been type checked yet.
Fixes <rdar://problem/48852402>.
`openUnboundGenericType` eagerly tries to add conditional requirements
associated with chain of parents of the given type if type has been
declared inside of constrained extension. But one of the parent types
might be unbound e.g. `A.B` which means it has to be opened, which
by itself, would add such requirements.
Resolves: rdar://problem/49371608
The test might want to be split in two, because it does both checks for
the output of the compilation, and the run time itself, but for now mark
it as executable, so it doesn't break the Android test suite (which
cannot execute tests).
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>
Many places on the testing scripts for Android have the ARMv7
architecture hardcoded. Modify all those instances to support both ARMv7
and AArch64.
Besides the paths being modified depending on the architecture, the
script is also modified to adapt to NDK beyond r14, where the headers
are not under the SDK root, but under a unified sysroot. Two new include
paths are passed to the compiler invocations (one the general one, one
the architecture specific one).
In order to link correctly, the -tools-directory is passed to the Swift
compiler invocation. In order to use a modern linker, the selected
linker in the CMake script is written in the lit.site.cfg.in files. The
system will prefer lld, but will fallback to gold. Plain ld will not be
used, since it cannot link correctly the binaries.
There's a new CMake variable named SWIFT_ANDROID_${ARCH}_ICU_DATA that
should point to libicudataswift.so for each architecture. This part of
ICU is necessary while running the test in the host, so it needs to be
uploaded. Since it is normally side by side with other ICU products, the
linker was finding it for free.
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.
The lit feature `objc_interop` is used as a proxy for the availability
of libdispatch and Foundation.
Although we don't support Obj-C on non-Apple platforms, we support
libdispatch and Foundation. Let's break up `objc_interop` into
finer-grained categories so we can run more tests on non-Apple
platforms.
This patch adds lit features `libdispatch` and `foundation` (currently
only enabled on Apple platforms) and removes the `objc_interop`
dependency from libdispatch tests.
