Expose the createStructType helper to clients of IRGenModule which want
to define types which won't ever be used elsewhere. This is just a
convenience--such clients could already have directly used the API on
llvm::Module directly.
In `addAbstractForFulfillments()`, FulfillmentMap (DenseMap) is
iterated to compute all the cache entries. Even the
non-deterministic iteration order doesn't affect the computed cache
entries, the requests to the evaluator during the process will be in
non-deterministic order. This will cause the fine-grain dependency file
generated to be non-deterministic. Use a `MapVector` to make sure
iteration order is deterministic.
rdar://147971980
Calls to the allocation functions use the same convention regardless of
which function, so if the functino being called is malloc and free,
provide a thunk with the appropriate convention.
rdar://142485229
In generic multi payload enums, if the payload was empty, we missed a check for that when storing the payload and always cleared out the extra tag byte.
This is a follow-up to d3e43bbe which resolved the issue for value types, but not for foreign reference types.
This change teaches IRGen that a base type of a C++ type might occupy less memory than its `sizeof`, specifically, it might only use `dsize` amount of memory.
rdar://147527755
Certain dynamic casts cannot work safely with isolated conformances,
regardless of what executor the code runs on. For such cases, reject
all attempts to conform to the type.
This is a value operation that can work just fine on lowered types,
so there's no need to carry along a formal type. Make the value/address
duality clearer, and enforce it in the verifier.
rdar://147872231
When an async typed throwing function had a result type that combined multiple fields into a single register, we created invalid IR, that could lead to compiler crashes or in some cases even miscompiles. With this fix we are mapping the result to the native representation before mapping it to the combined result type.
The mapTypeIntoContext() call in visitFullApplySite() was not
necessary.
The type in question is already fully substituted and should
no longer contain type parameters.
However, it can contain archetypes, which is what caused
mapTypeIntoContext() to assert.
Indeed, this case where the return type is generic but still
loadable wasn't covered by our test suite.
- Fixes https://github.com/swiftlang/swift/issues/80020.
- Fixes rdar://147051717.
The module name changes the symbol mangling, and also causes
TBDGen to emit linker directives. To separate out these two
behaviors, introduce a terrible hack. If the module name
contains a semicolon (`;`), the part before the semicolon
is the module name for mangling, and the part after the
semicolon is the module name for linker directives.
If there is no semicolon, both module names are identical,
and the behavior is the same as before.
An "abstract" ProtocolConformanceRef is a conformance of a type
parameter or archetype to a given protocol. Previously, we would only
store the protocol requirement itself---but not track the actual
conforming type, requiring clients of ProtocolConformanceRef to keep
track of this information separately.
Record the conforming type as part of an abstract ProtocolConformanceRef,
so that clients will be able to recover it later. This is handled by a uniqued
AbstractConformance structure, so that ProtocolConformanceRef itself stays one
pointer.
There remain a small number of places where we create an abstract
ProtocolConformanceRef with a null type. We'll want to chip away at
those and establish some stronger invariants on the abstract conformance
in the future.
* [CS] Decline to handle InlineArray in shrink
Previously we would try the contextual type `(<int>, <element>)`,
which is wrong. Given we want to eliminate shrink, let's just bail.
* [Sema] Sink `ValueMatchVisitor` into `applyUnboundGenericArguments`
Make sure it's called for sugar code paths too. Also let's just always
run it since it should be a pretty cheap check.
* [Sema] Diagnose passing integer to non-integer type parameter
This was previously missed, though would have been diagnosed later
as a requirement failure.
* [Parse] Split up `canParseType`
While here, address the FIXME in `canParseTypeSimpleOrComposition`
and only check to see if we can parse a type-simple, including
`each`, `some`, and `any` for better recovery.
* Introduce type sugar for InlineArray
Parse e.g `[3 x Int]` as type sugar for InlineArray. Gated behind
an experimental feature flag for now.
