This test is technically scaling linearly in the metrics being
checked, but it was still taking 5+ minutes to type check. Reduce the
upper bound so it finishes in a reasonable amount of time.
When favoring particular constraints in a disjunction, don't remove
the old disjunction and create a new one---it's just churn in the
constraint system. Instead, favor the constraints that need it.
This technically flips the SR-139 test case from "too complex" to
being fast enough, but it's still fairly slow.
Otherwise certain modules don't import correctly when built against an
Apple-internal SDK. Should have no effect when using the public SDK,
but we try to minimize divergence between the public and
Apple-internal test suites.
rdar://problem/48513002
This turns out to be the only problem on iOS and tvOS. Oops! macOS
still has some actual failing overlays as tracked by SR-9847.
(We should also add this search path to
ParseableInterface/verify_all_overlays.py.)
rdar://problem/48458622
We have to set the SILFunction's 'weakLinked' flag in the defining
module too, so that it can be serialized. Otherwise when we
deserialize it we are not weak linking calls to the function.
@_optimize(none) does not prevent LLVM from optimizing the function, and the LLVM
optimizer was able to inline blackHole() and elide the metadata access altogether.
If the conforming type is generic, we have to treat the conformance as
resilient if it is defined outside of the current module.
This is because it can resiliently change from being non-dependent
to dependent.
This changes the Swift resource directory from looking like
lib/
swift/
macosx/
libswiftCore.dylib
libswiftDarwin.dylib
x86_64/
Swift.swiftmodule
Swift.swiftdoc
Darwin.swiftmodule
Darwin.swiftdoc
to
lib/
swift/
macosx/
libswiftCore.dylib
libswiftDarwin.dylib
Swift.swiftmodule/
x86_64.swiftmodule
x86_64.swiftdoc
Darwin.swiftmodule/
x86_64.swiftmodule
x86_64.swiftdoc
matching the layout we use for multi-architecture swiftmodules
everywhere else (particularly frameworks).
There's no change in this commit to how Linux swiftmodules are
packaged. There's been past interest in going the /opposite/ direction
for Linux, since there's not standard support for fat
(multi-architecture) .so libraries. Moving the .so search path /down/
to an architecture-specific directory on Linux would allow the same
resource directory to be used for both host-compiling and
cross-compiling.
rdar://problem/43545560
This initialization pattern can only be used if there is a backward deployment
layout (IRGen calls this ClassMetadataStrategy::FixedOrUpdate) or if we are
running on a newer Objective-C runtime that supports class metadata update
hooks (IRGen calls this ClassMetadataStrategy::Update).
If neither condition holds, we must trap here to avoid undefined behavior.
If we know our deployment target has a new Objective-C runtime, we can
emit fixed metadata for classes with resilient types even if those
types do not appear in the YAML legacy type info.
Fixes <rdar://problem/47649465>.
Looks like obsoleted initializer has been removed,
and there are no solutions available for 'init(truncatingBitPattern:)'
which leads to performance regression with designated types enabled.
Resolves: rdar://problem/48061151
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.
