Optimizes String operations with constant operands.
Specifically:
* Replaces x.append(y) with x = y if x is empty.
* Removes x.append("")
* Replaces x.append(y) with x = x + y if x and y are constant strings.
* Replaces _typeName(T.self) with a constant string if T is statically known.
With this optimization it's possible to constant fold string interpolations, like "the \(Int.self) type" -> "the Int type"
This new pass runs on high-level SIL, where semantic calls are still in place.
rdar://problem/65642843
LLVM doesn't have a stable ABI for Float16 on x86 yet; we're working with Intel to get that fixed, but we don't want to make the type available on macOS until a stable ABI is actually available, because we'd break binaries compiled before any calling convention changes if we do.
This function walks all the fields of a struct, class, or tuple, and calls
`body` with the name, offset, and type of each field. `body` can perform
any required work or validation, returning `true` to continue walking fields
or `false` to stop immediately.
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.
