Using && here causes us to go down a SILGen path that guarantees that self will
be evaluated over the entire && expression instead of just the LHS. This cause
the uniqueness check to always return false at -Onone. At -O, the optimizer is
smart enough to remove this issue.
rdar://33358110
makeUnique hoisting can create a situation where we hit an assert in
_reserveCapacityAssumingUniqueBuffer that the buffer is not unique if we use
_makeMutableAndUniqueOrPinned to replace
_makeUniqueAndReserveCapacityIfNotUnique.
It is actually fine do to the replacement because we will make the buffer unique
_reserveCapacityAssumingUniqueBuffer if the capacity is zero so adjust the
assert accordingly.
do {
if (someCond) {
// array.append(...)
_makeUniqueAndReserveCapacityIfNotUnique(&array)
_reserveCapacityAssumingUniqueBuffer(&array)
_appendElementAssumeUniqueAndCapacity(&array, …)
} else {
// array[i] = …
_makeMutableAndUniqueOrPinned(&array)
addr = _getElementAddress(&array)
store 1, addr
}
} while();
to:
_makeMutableAndUniqueOrPinned(&array) // does not replace empty arrays.
do {
if (someCond) {
// array.append(...)
_reserveCapacityAssumingUniqueBuffer(&array) // hit the assert.
_appendElementAssumeUniqueAndCapacity(&array, …)
} else {
// array[i] = …
addr = _getElementAddress(&array)
store 1, addr
}
} while();
Tested by the performance test if we build the stdlib with assertions.
rdar://34149935
* Unify the capitalization across all user-visible error messages (fatal errors, assertion failures, precondition failures) produced by the runtime, standard library and the compiler.
* Update some more tests to the new expectations.
This overload allows `String.filter` to return a `String`, and not
`[Character]`.
In the other hand, introduction of this overload makes `[123].filter`
somewhat ambiguous in a sence, that the compiler will now prefer an
implementatin from a more concrete protocol, which is less efficient for
arrays, therefore extra work is needed to make sure Array types fallback
to the `Sequence.filter`.
Implements: <rdar://problem/32209927>
- remove additional 'characters' references from String docs
- improved language around escaping pointer arguments
- key path type abstracts
- codable type abstract revisions
- a few more NSString API fixes
* Give Sequence a top-level Element, constrain Iterator to match
* Remove many instances of Iterator.
* Fixed various hard-coded tests
* XFAIL a few tests that need further investigation
* Change assoc type for arrayLiteralConvertible
* Mop up remaining "better expressed as a where clause" warnings
* Fix UnicodeDecoders prototype test
* Fix UIntBuffer
* Fix hard-coded Element identifier in CSDiag
* Fix up more tests
* Account for flatMap changes
array.append_element(newElement: Element)
array.append_contentsOf(contentsOf newElements: S)
And allow early inlining of them.
Those functions will be needed to optimize Array.append(contentsOf)
Previously often times when casting a value, we would just pass along the
cleanup of the uncasted value. With semantic SIL this is no longer correct since
the cleanup now needs to be on the cast result.
This caused problems for certain usages of Builtin.castToNativeObject(...) by
the stdlib. Specifically, the stdlib was using this on AnyObject values that
were not necessarily native. Since we were recreating the cleanup on the native
value, a swift native release was being used =><=.
In this commit I solve this problem by:
1. Adding an assert in Builtin.castToNativeObject(...) that ensures that any value
passed to Builtin.castToNativeObject() is known conservatively to use swift
native reference counting.
2. I changed all uses where we do not have a precondition of a native ref
counting type to use Builtin.castToUnknownObject(...).
3. I added a new Builtin called Builtin.unsafeCastToNativeObject(...) that does
not have the compile time check. I used this to rewrite callsites in the stdlib
where we know via preconditions that an AnyObject will dynamically always be
native.
rdar://29791263
Although it’s called via _slowPath the compiler sometimes inlines it, because it considers it to be a trivial function.
This change gives small code size improvements for benchmarks which deal with arrays.
rdar://problem/30210047
