This is essentially a long-belated follow-up to Arnold's #12606.
The key observation here is that the enum-tag-single-payload witnesses
are strictly more powerful than the XI witnesses: you can simulate
the XI witnesses by using an extra case count that's <= the XI count.
Of course the result is less efficient than the XI witnesses, but
that's less important than overall code size, and we can work on
fast-paths for that.
The extra inhabitant count is stored in a 32-bit field (always present)
following the ValueWitnessFlags, which now occupy a fixed 32 bits.
This inflates non-XI VWTs on 32-bit targets by a word, but the net effect
on XI VWTs is to shrink them by two words, which is likely to be the
more important change. Also, being able to access the XI count directly
should be a nice win.
This will ensure that additional target executables can not be added to the rest
of the swift project without anyone noticing since the non-stdlib parts of
Swift's cmake will not have visibility of the declaration unless they change the
cmake lookup paths.
If a key path literal appears in a generic context with an existing context descriptor, this will allow us to
save some code size by not having to emit a separate GenericEnvironment descriptor.
This can be used by compiler-generated code as a size optimization for metadata access, using a
mangled name instead of possibly many open-coded metadata calls. It can also allow reflection
libraries outside of the standard library to turn type reference strings into in-process metadata
pointers in a robust way. rdar://problem/46451849
Not only was this affecting performance when building from parseable
interfaces, but we'd also want these to be inlined for any sort of
bounds-checking diagnostics / static analysis we might get in the
future.
* Minor improvements to CGFloat
Apparently init(exactly:) was never implemented for CGFloat, so let's fix that. Also includes minor cleanup for the .magnitude property.
* Add transparent annotations to some other CGFloat things.
These implementations did not produce the same hash values as the raw value. RawRepresentable provides a correct hashing implementation by default, so let’s just use that.
Protocols in resilient libraries that wish to provide a default implementation of hashing need to do so by providing a hash(into:) implementation.
hashValue has been deprecated as a Hashable requirement in SE-0206. Implementing only it in a protocol extension curses conforming types to get deprecation warnings by default.
If one thinks about it, swift's build has two sections: a runtime or target
section (i.e. ./stdlib) and a host section (everything
else). swift-reflection-test is an abberation from that pattern since it is
built for target platforms but is in the section of host tools.
In this commit, I move it into ./stdlib. Beyond being a bitter location
conceptually this will additionally allow me to avoid a dependency cycle in
between the compiler and the stdlib build.
After this, there is only one more target in the compiler code: swift-lang. From
talking with Xi Ge, we can move that into its own separate project as a
package. Once that is done, I will not have any more cycles.
While declaration mangling now does the right thing for parameter lists,
the function type mangling unfortunately still models the parameter list
as a single tuple node.
Change the runtime's behavior to match the AST mangler, which wraps
a single tuple-typed parameter in a tuple node, so that we can produce
different mangling trees for function types taking multiple arguments
versus a single tuple argument.
* cmake: Propagate SWIFT_DARWIN_ENABLE_STABLE_ABI_BIT to overlay builds.
* runtime: Clear the correct bit in getROData()
* test/IRGen/objc_class_export.swift: Allow either is-Swift bit.
* test/stdlib/SwiftObjectNSObject.swift: Allow either name for SwiftObject.
Currently ignored, but this will allow future compilers to pass down source location information for cast
failure runtime errors without backward deployment constraints.
The SDK directory is now confusing as the Windows target also has a SDK
overlay. In order to make this more uniform, move the SDK directory to
Darwin which covers the fact that this covers the XNU family of OSes.
The Windows directory contains the SDK overlay for the Windows target.
