In SILGenPattern, we need to be able to unforward cleanups when we explode
tuples. Thus we can't use RValue in SILGenPattern since it may implicitly
explode tuples (which without modifying RValue itself we can not
unforward). This patch removes a specific RValue usage that we can replace with
the use of a ManagedValue instead.
rdar://49903264
Error structs synthesized by ClangImporter can be renamed using SWIFT_NAME() to syntactically appear anywhere in the type hierarchy with any name, but they should always be mangled as `__C_Synthesized.related decl ‘e’ of <Objective-C enum name>`. Unforunately, when SWIFT_NAME() was used to nest the error struct inside another type, an ASTMangler bug would cause it to be mangled as `<parent type>.related decl ‘e’ of <Objective-C enum name>`, and an ASTDemangler bug would also require a valid parent type. This created a mismatch between the compiler’s and runtime’s manglings which caused crashes when you tried to match the imported error struct in a `catch`.
This PR corrects the compiler bugs so that it generates the mangling the runtime expects. This is theoretically ABI-breaking, but as far as I can determine nobody has shipped the incorrectly mangled names, presumably because they crash when you try to use them.
Fixes <rdar://problem/48040880>.
This is a large patch; I couldn't split it up further while still
keeping things working. There are four things being changed at
once here:
- Places that call SILType::isAddressOnly()/isLoadable() now call
the SILFunction overload and not the SILModule one.
- SILFunction's overloads of getTypeLowering() and getLoweredType()
now pass the function's resilience expansion down, instead of
hardcoding ResilienceExpansion::Minimal.
- Various other places with '// FIXME: Expansion' now use a better
resilience expansion.
- A few tests were updated to reflect SILGen's improved code
generation, and some new tests are added to cover more code paths
that previously were uncovered and only manifested themselves as
standard library build failures while I was working on this change.
This allows the conversion of the Windows `BOOL` type to be converted to
`Bool` implicitly. The implicit bridging allows for a more ergonomic
use of the native Windows APIs in Swift.
Due to the ambiguity between the Objective C `BOOL` and the Windows
`BOOL`, we must manually map the `BOOL` type to the appropriate type.
This required lifting the mapping entry for `ObjCBool` from the mapped
types XMACRO definition into the inline definition in the importer.
Take the opportunity to simplify the mapping code.
Adjust the standard library usage of the `BOOL` type which is now
eclipsed by the new `WindowsBool` type, preferring to use `Bool`
whenever possible.
Thanks to Jordan Rose for the suggestion to do this and a couple of
hints along the way.
This addresses the follow up test case discussed in PR23651. Windows
will not promote a macro literal suffixed with `ll` or `i64` to an
unsigned long long even upon an overflow. This tests that the corner
case behaviour for importing a long long literal matches the platform
expectations.
Windows will keep the imported type as `signed long long` rather than
`unsigned long long` as per the Microsoft compiler behaviour. This
breaks the tests for this case. Unfortunately, this is one of those
areas which must differ.
This test ensures that we correctly translate the anonymous enumeration
value. However, this is an odd case within the specification.
C11 6.7.2.2p2:
"The expression that defines the value of an enumeration constant shall
be an integer constant expression that has a value representable as an
`int`."
C11 6.7.2.2p4:
"Each enumerated type shall be compatible with `char`, a signed integer
type, or an unsigned integer type. The choice of type is
implementation-defined, but shall be capable of representing the values
of all the members of the enumeration."
C11 6.7.2.2p3:
"The identifiers in an enumerator list are declared as constants that
have type `int` and may appear wherever such are permitted."
Because the enumeration is anonymous, the value could never be written
as spelled. This type is imported as an `int` on Windows as per the ABI
and as an `unsigned long` on LP64 targets.
Non-generic classes with resilient ancestry do not have statically-emitted
metadata, so we can now emit an Objective-C resilient class stub instead.
Also, when emitting an Objective-C category, reference the class stub if
the class has resilient ancestry; previously this case would hit an assert.
Note that class stubs always start with a zero word, with the address point
pointing immediately after. This works around a linker issue, where the
linker tries to coalesce categories and gets confused upon encountering a
class stub.
* Teach the importer to import any vector type as SIMDN<Scalar>.
Instead of having a known set of vector types, check to see if the
element type conforms to SIMDScalar; if it does, see if we have a
SIMDN defined with the right number of elements. If both are satisfied,
import the vector type as that Swift type.
By making this change, we gain the ability to import vector types
that aren't defined in terms of the Darwin simd module, which lets
us use C API with vector types on other platforms. It also lets us
import *every* vector type that Swift can represent, rather than the
small subset that are currently hardcoded.
* Increased test coverage for increased SIMD types that we can import.
Includes some minor cleanup from review. Also eliminates the old
simd_sans_simd test, since we can now import all of these types even when the simd module isn't imported.
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.
When calling a witness table accessor, IRGen was forcing the
conforming type to have complete metadata, even though only abstract
metadata is required for that query. This could cause cyclic metadata
dependencies when checking conditional conformances.
Fixes SR-5958.
When an enum is imported as an error, the imported type itself becomes
a nested type 'Code' of its wrapper type, so you get a type like
'MyError.Code'. However in the mangling grammar the type is a
child of a module and not another type.
This was tripping up TypeDecoder, which would check parent types for
validity and throw out the demangling since it looked invalid.
However since this case really is valid, just skip the whole parent
type mess when the type is imported and non-generic.
Now that the runtime fills in the private slots with conditional requirement
information, we can always use mangled names for inherited conformances.
Fixes rdar://problem/46282080.
Rather than having the witness table instantiation function copy the
instantiation arguments that corresponding to conditional requirements
into the private area, have the runtime do it. We’re going to depend on
these lining up anyway (and the witness table can of course have *more*
private slots that it manages some other way), so centralize the code.
More of rdar://problem/46282080.
Introduce a new runtime entry point, swift_getAssociatedConformanceWitness(),
which extracts an associated conformance witness from a witness table.
Teach IRGen to use this entry point rather than loading the witness
from the witness table and calling it directly.
There’s no advantage to doing this now, but it is staging for changing the
representation of associated conformances in witness tables.
Collapse the generic witness table, which was used only as a uniquing
data structure during witness table instantiation, into the protocol
conformance record. This colocates all of the constant protocol conformance
metadata and makes it possible for us to recover the generic witness table
from the conformance descriptor (including looking at the pattern itself).
Rename swift_getGenericWitnessTable() to swift_instantiateWitnessTable()
to make it clearer what its purpose is, and take the conformance descriptor
directly.
For a resilient protocol that has defaulted associated types, emit
default associated conformance witnesses that compute associated
conformances based on that default witness.
This completes the implementation of resilience protocols that
add new, defaulted associated types, rdar://problem/44167982.
Associated conformance descriptors are aliases that refer to associated
conformance requirements within a protocol descriptor’s list of
requirements. They will be used to provide protocol resilience against
the addition of new associated conformance requirements (which only makes
sense for newly-introduced, defaulted associated types).
When an associated type witness has a default, record that as part of
the protocol and emit a default associated type metadata accessor into the
default witness table. This allows a defaulted associated type to be
added to a protocol resiliently.
This is another part of rdar://problem/44167982, but it’s still very
limiting because the new associated type cannot have any conformances.
When we’re creating an associated type witness metadata accessor for
resilience reasons, but the associated type witness doesn’t involve any
type parameters, directly form the type metadata reference (and don’t
cache it).
While here… update all of the IRGen/SILGen test cases perturbed by the
introduction of resilient associated type access patterns.
