Previously, we skipped checking the return type of a function for safety
as we expected to warn at the use of the returned value:
let x = returnsUnsafe()
usesUnsafe(x) // warn here
Unfortunately, this resulted in missing some unsafe constructs that can
introduce memory safety issues when the use of the return value had a
different shape resulting in false negatives for cases like:
return returnsUnsafe()
or
usesUnsafe(returnsUnsafe())
This PR changes the analysis to always take return types of function
calls into account.
rdar://157237301
To be able to constant fold string interpolation, the right semantic attributes must be in place.
Also, the interpolation's write function must be inlinable.
For the _typeName constant folding, a semantic attribute is required.
In particular, if value is `Any` in a generic context, then `type(of: value)` is
`Any.Protocol` which is never considered optional. As a result, the first
clause here was never actually being used for `print()` or other similar paths.
(Curiously, it _was_ used for string interpolation.)
This changes how we test for an optional type so that the first clause is consistently used for all optionals, even when they are wrapped in `Any` containers.
Fortunately? `print()` was producing the right results for
optionals because of a dynamic cast bug that failed to
unwrap optionals in these same contexts. <sigh>
This is a giant squashing of a lot of individual changes prototyping a
switch of String in Swift 5 to be natively encoded as UTF-8. It
includes what's necessary for a functional prototype, dropping some
history, but still leaves plenty of history available for future
commits.
My apologies to anyone trying to do code archeology between this
commit and the one prior. This was the lesser of evils.
The functions in LibcShims are used externally, some directly and some through @inlineable functions. These are changed to SWIFT_RUNTIME_STDLIB_SPI to better match their actual usage. Their names are also changed to add "_swift" to the front to match our naming conventions.
Three functions from SwiftObject.mm are changed to SPI and get a _swift prefix.
A few other support functions are also changed to SPI. They already had a prefix and look like they were meant to be SPI anyway. It was just hard to notice any mixup when they were #defined to the same thing.
rdar://problem/35863717
@effects is too low a level, and not meant for general usage outside
the standard library. Therefore it deserves to be underscored like
other such attributes.
Aggressively remove all `@inlinable` from any function that's
`@inline(never)` to see the impact.
`@inlinable @inline(never)` is a potential code smell. While it might
expose some optimization and specialization opportunities to the
optimizer, it's most commonly a sign that more thought is needed.
As pointed out in Ole Begeman's blog:
https://oleb.net/blog/2016/09/playground-print-hook/
The playground print hook is being initialized a a non-null noop hook,
which causes the fast paths in the print functions to be unused, and
forcing the creation of a tee stream for things that have nothing to
do with playgrounds. It is sad that no one noticed this...
Include the initial implementation of _StringGuts, a 2-word
replacement for _LegacyStringCore. 64-bit Darwin supported, 32-bit and
Linux support in subsequent commits.
- Revise Equatable and Hashable for synthesized requirements
- Complete Strideable and stride(from:...:by:) documentation
- Revise DoubleWidth type docs
- Add complexity notes for Set.index(of:) and .contains(_:)
- Fix typos in Set.formUnion docs
- Add missing axioms for SetAlgebra (SR-6319)
- Improve guidance for description and debugDescription
- Add note about the result of passing duplicate keys to
Dictionary(uniqueKeysWithValues:)
- Fix typo in BinaryInteger docs
- Update Substring docs with better conversion example
- Improve docs for withMemoryRebound and isKnownUniquelyReferenced
- Add missing docs not propagated from protocols
When printing a tuple via print(...), print tuple labels when they are
available. This is possible now that the runtime metadata properly
stores tuple labels. Fixes rdar://problem/23130016.
