Adjust the division operation to ensure that we get an integral value
back. Without this, we would attempt to shift a floating point value
by bitwise operations which is not supported.
Most of the changes fall into a few categories:
* Replace explicit "x86_64" with %target-cpu in lit tests
* Cope with architecture differences in IR/asm/etc. macOS-specific tests
* SR-12486: `T.self is Any.Protocol` is broken
This turned out to be fallout from https://github.com/apple/swift/pull/27572
which was in turn motivated by our confusing metatype syntax when generic variables are bound to protocols.
In particular, the earlier PR was an attempt to make the expression
`x is T.Type` (where `T` is a generic type variable bound to a protocol `P`)
behave the same as
`x is P.Type` (where `P` is a protocol).
Unfortunately, the generic `T.Type` actually binds to `P.Protocol` in this case (not `P.Type`), so the original motivation was flawed, and as it happens, `x is T.Type` already behaved the same as `x is P.Protocol` in this situation.
This PR reverts that earlier change and beefs up some of the tests around these behaviors.
Resolves SR-12486
Resolves rdar://62201613
Reverts PR#27572
Clean up a few general patterns that are now obviated by canImport
This aligns more generally with the cleanup that the Swift Package
Manager has already done in their automated XCTest-plumbing tool in
apple/swift-package-manager#1826.
Currently it's possible to have a type conflict between different
requirements deduced as the same type which leads to incorrect
diagnostics. To mitigate that let's adjust how "fixed" requirements
are stored - instead of using resolved type for the left-hand side,
let's use originating generic parameter type.
If there is a conditional requirement failure associated with
member/function reference used in a call let's increase a score
of a fix for such failure because it renders member/function
unreachable in current context or with a given set of arguments.
One of our Ubuntu 16.04 CI machines is seeing different variations
of the std::__once_call_impl<>() constructor than the ones we're already filtering out.
Resolves rdar://64267618
These tests are marked XFAIL or UNSUPPORTED because either the tests:
require libc annotation, require Mach-O support, don't recognize calls to
swift-autolink-extract, requires porting alongside Linux, or rely on simd
which is not present.
Additionally, explicit REQUIRES for tsan/asan/fuzzer are added to some
tests, since OpenBSD does not support these sanitizers or fuzzers, since
it's nicer to mark that with REQUIRES rather than XFAIL.
The Swift standard library should not export weak symbols. Ensure that
no public weak symbols are defined in the standard library by adding a
test case. This would have identified the issue introduced by the
recent changes for the runtime.
The static version of the standard library was leaking symbols in the
`llvm::` namespace which would result in ODR violations were the
artifact linking against `LLVMSupport` (via another dependency). In
particular, `llvm::SmallVector` and `llvm::StringSwitch` symbols were
being leaked. This adds a test case specifically for the static variant
of the library. The dynamic variant of the library is already tested in
a separate test.
This test was disabled back in 2017 when the new integer protocols were
landing due to regressions in error messages. It is better to have a
working test that verifies the desired behavior (UnicodeScalar not
supporting arithmetic and the type checker producing somewhat readable
messages), rather than a disabled test because the error messages are
not perfect.
I don't see any reason to split the tests like this. I merged the tests
into the biggest and best-organized test file.
I also removed the `REQUIRES: OS=macosx` line and made some small
adjustments to the test to make it cross-platform.
Add a test to ensure that the standard library does not accidentally end
up with symbols in the `llvm::` namespace. The LLVMSupport symbols for
now are namespaced to `__swift::__runtime` with the desire that they
will move into `swift::` and become vended in the swift namespace.
Platform defines sem_open in Swift that calls through to the underlying
platform functions because sem_open is variadic. However, the
definitions here assume sem_t is non-nullable, but this assumption only
holds when the platform has nullability annotations on the semaphore
type, or the semaphore type on the platform is not an opaque pointer.
On OpenBSD specifically, the semaphore type is an opaque pointer without
any nullability annotations. This means that the type gets inferred as
UnsafeMutablePointer<sem_t?>? instead of UnsafeMutablePointer<sem_t>?.
To make sure the pointer values returned and their types match, we
introduce a conditional typealias.
The other option is to coerce everything to UnsafeMutablePointer<sem_t>?
but this would be a rather blunt instrument. While sem_open is public in
stdlib, it is not so much codified stdlib API, so this is a slightly
nicer approach.
The `-force-single-frontend-invocation` flag predates WMO and is now an
alias for `-whole-module-optimization`. We should use the latter and let
the former fade into history.
