The SIMDOperators module was being added prior to SwiftOnoneSupport, which
resulted in the import library target for Windows not being setup prior to use.
As a result, we would link against the DLL rather than the import library which
is not supported (except as a MinGW hack in the binutils linker). Re-order the
registration to ensure that the target is setup already.
Within the (single) implementation of abs(_:), dynamically check whether
the numeric type and its `Magnitude` are of the same type and, if so,
return the result of `magnitude`. This ensures that we do the right thing
with respect to (e.g.) floating point values like -0.0, without resorting
to overloading of abs(_:).
Add in a fast-path for Strings created from Substring which covers the
entire String. Put String-from-Substring behind a non-inlinable
resilience barrier for future flexibility.
_modify mustn’t leave Collection storage in an inconsistent state when the code to which we’re yielding happens to throw. In practice this means that any cleanup code must happen in defer blocks before the yield.
Fix Dictionary to do just that and add tests to cover this functionality (as well as some other aspects of _modify).
The standard library has two versions of the `abs(_:)` function:
```
func abs<T : SignedNumeric>(_ x: T) -> T where T.Magnitude == T
func abs<T : SignedNumeric & Comparable>(_ x: T) -> T
```
The first is more specialized than the second because `T.Magnitude` is
known to conform to `Comparable`. Indeed, it’s a more specialized
implementation that returns `magnitude`.
However, this overload behaves oddly: in the expression `abs(-8)`, the type
checker will pick the first overload because it is more specialized. That’s
a general guiding principle for overloading: pick the most specialized
overload that works.
However, to select that overload, it needs to pick a type for the literal
“8” for which that overload works, and it chooses `Double`. The “obvious”
answer, `Int`, doesn’t work because `Int.Magnitude == UInt`.
There is a conflict between the two rules, here: we prefer more-specialized
overloads (but we’ll fall back to less-specialized if those don’t work) and we prefer to use `Int` for integer literals (but we’ll fall back to `Double` if it doesn’t work). We have a few options from a type-checker
perspective:
1. Consider the more-specialized-function rule to be more important
2. Consider the integer-literals-prefer-`Int` rule to be more important
3. Call the result ambiguous and make the user annotate it
The type checker currently does #1, although at some point in the past it
did #2. Moving forward, #1 is a better choice because it prunes the number
of overloads that need to be considered: if the more-specialized overload
succeeds its type-check, the others need not be considered. It’s also
easier to reason about than the literal-scoring approach, because there can
be a direct definition for “more specialized than” that can be reasoned
about.
I think we should dodge the issue by removing the more-specialized version
of `abs(_:)`. Its use of `magnitude` seems unlikely to provide a
significant performance benefit, and the presence of overloading either
forces us to consider both overloads always (which is bad for type checker
performance) or accept the regression that `abs(-8)` is `Double`. Better
to eliminate the overloading and, if needed in the future, find a better
way to introduce the more-specialized implementation without it being a
separate signature.
Fixes rdar://problem/42345366.
We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.
Patch produced by
for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done
Hand-incrementing the loop variable allows us to skip overflow
detection, and will permit more vectorization improvements in the
future. For now, it gives us perf improvements in nano-benchmarks.
Add the setjmp module which was missing. The roughly equivalent
function is `_setjmp`. Unfortunately, it is not marked as
`__attribute__((__returns_twice__))`.
Resilient conformances now put all witnesses into the resilient witness
table, so optimize away the witness table pattern for such cases. Teach
the runtime to fill in the protocol conformance descriptor, because that’s
the only bit of real information that would be in the pattern.
This is a minor optimization enabled by rdar://problem/46282080.
The object file extension on Windows is `.obj` rather than `.o`. Ensure
that we get the extension correct when compiling for Windows.
Furthermore, ensure that we install with the correct extension when
installing a cross-compiled image. As we may be using the homegrown
cross-compilation system, we must explicitly handle the extension
ourselves. This allows nearly a 100 additional tests to pass on
Windows.
Emit mangled inherited protocol witnesses into the resilient witness table,
and realize them when we instantiate the resilient witness table. Don’t
put mangled inherited protocol witnesses into non-resilient witness tables:
there is no efficient way to make sure they are realized, so keep the
previous instantiation-function approach.
Implements the rest of rdar://problem/46282080.
Include some tuning and tweaking to reduce the constant factors
involved in string comparison. This yields considerable improvement on
our micro-benchmarks, and allows us to make less inlinable code and
have a smaller ABI surface area.
Adds more extensive testing of corner cases in our existing
fast-paths.
All latiny (<0x300) scalars have normalization boundaries before them,
so when asking if memory containing a scalar encoded in valid UTF-8
has a boundary before it, check if the leading byte definitely encodes
a scalar less than 0x300.
When in a post-binary-prefix-scan fast-path, we need to make sure we
are comparing a full-segment scalar, otherwise we miss situations
where a combining end-of-segment scalar would be reordered with a
prior combining scalar in the same segment under normalization in one
string but not the other.
This was hidden by the fact that many combining scalars are not
NFC_QC=maybe, but those which are not present in any precomposed form
have NFC_QC=yes. Added tests.
Defining a custom iterator for the UTF16View avoid some redundant
computation over the indexing model. This speeds up iteration by
around 40% on non-ASCII strings.
Introduce a WinSDK overlay for Windows. This allows us to define some
shared constants that are not correctly imported right now. This cleans
up the logic in the swift side of things and aids in the bring up.
Now that we have a SDK overlay for Windows, we should structure the tree
according to the OS family.
