Fix the type of the `alloca` created by `GenPack`'s for type metadata
and witness tables by fixing its callee, `emitDynamicAlloca` to always
return a `StackAddress` whose `Address`' type is the one specified by
the caller.
rdar://109540863
When called on a string that is not uniquely referenced,
`String.reserveCapacity(_:)` ignores the current capacity, using
the passed-in capacity for the size of its new storage. This can
result in an underallocation and write past the end of the new
buffer.
This fix changes the new size calculation to use the current UTF-8
count as the minimum. Non-native or non-unique strings
now allocate the requested capacity (or space enough for the
current contents, if that's larger than what's requested).
rdar://109275875
Fixes#53483
When completing, we call `getExistentialType` on the contextual type to get a nice and concise description of the contextual parameter’s type that doesn’t contain archetypes and which we can also serialize into a USR so we are able to calculate type relations for code completion results from the code completion cache.
When completing in a position that has a contextual type which only constrains one of two primary associated protocol types, this fails because `getExistentialType` (which calls `getDependentUpperBounds`) tries to form a `ParameterizedProtocolType`, which fails since not all primary associated types have been constrained.
AFAICT the fix here is to just fall back to the default behavior of returning the plain protocol type instead of `abort`ing.
rdar://108835466
We shouldn't be allocating placeholders for type
variables in the permanent arena, and we should be
caching them such that equality works.
To achieve this, we need to introduce a new
"solver allocated" type property. This is required
because we don't want to mark placeholder types
with type variable originators as themselves having
type variables, as it's not part of their structural
type. Also update ErrorType to use this bit, though
I don't believe we currently create ErrorTypes
with type variable originators.
In some Linux setups, one might need to provide extra arguments to setup
the environment for invocations done during the tests. The Swift
frontend and driver already had a mechanism to provide those arguments
in the shape of `SWIFT_FRONTEND_TEST_OPTIONS` and
`SWIFT_DRIVER_TEST_OPTIONS`. `swift-ide-test` was sadly missing the same
feature, which meant that many tests might fail or tests against the
incorrect environment.
The changes implement the `SWIFT_IDE_TEST_TEST_OPTIONS` mechanism to
cover that gap.
We can't assume that we will always find a viable witness for a protocol
requirement when typechecking a `.swiftinterface` file. The assert that assumed
there would be a match could fail when building a broken interface or building
a valid interface with a broken SDK, causing crashes instead of emitting
diagnostics.
Resolves rdar://108688535
Rather than eagerly binding them to holes if the
sequence element type ends up being Any, let's
record the CollectionElementContextualMismatch fix,
and then if the patterns end up becoming holes,
skip penalizing them if we know the fix was
recorded. This avoids prematurely turning type
variables for ExprPatterns into holes, which
should be able to get better bindings from the
expression provided. Also this means we'll apply
the logic to non-Any sequence types, which
previously we would give a confusing diagnostic
to.
As an optimization, there is a fast-cast to non-final classes that just
compares isa pointers. If the source of the cast is an Optional<class>,
though, it's not allowed to "directly compare the isa-pointer"; because
the source might be Optional.none, i.e. null.
Add a check for nil when emitting the fast class cast.
rdar://108614878
We started using clang to emit the _OBJC_PROTOCOL_ definition.
But we would use a different name for the proto_list definition than clang.
"OBJC_LABEL_PROTOCOL$" (objc)
|--> OBJC_PROTOCOL
"\01l_OBJC_LABEL_PROTOCOL$_" (swift)
|--> OBJC_PROTOCOL
If an Objective C object also emitted the same protocol definition you could
end up in a situation where both clang's and swift's proto_list definitions
point to the same protocol definition.
Older linkers don't like that.
rdar://108505376
Only fully resolved substitutions are eligible to be considered
as conflicting, if holes are involved in any position that automatically
disqualifies a generic parameter.
Resolves: rdar://108534555
Resolves: https://github.com/apple/swift/issues/63450
Code like that is usually indicative of programmer error, and does not
round-trip through module interface files since there is no source
syntax to refer to an outer generic parameter.
For source compatibility this is a warning, but becomes an error with
-swift-version 6.
Fixes rdar://problem/108385980 and https://github.com/apple/swift/issues/62767.
The new logic no longer includes non-generic parent types as part
of the type reference.
This also combines the 32- and 64-bit tests validations, since they
were identical for this test anyway.
This is a more correct fix for the issue that inspired PR #62854.
In particular, this does not change the numbering of generic
argument levels, and so does not break generic type parameter
lookups.
Added a new test case to verify that nested types that mix
generics and non-generics in different ways consistently identify
the correct generic argument labels.
Allowed SILFunctionType instances for pseudogeneric coroutines without
signatures to be created. Such instances are created by
SILTypeSubstituter::substSILFunctionType when SILGen'ing a conformance
of a pseudogeneric type to a protocol featuring a coroutine requirement.
rdar://81421394
Because `_taskLocalValuePush` and `_taskLocalValuePop` can result in calls
to `swift_task_alloc` and `swift_task_dealloc` respectively, and because
the compiler hasn't been taught about that (e.g.
`SILInstruction::isAllocatingStack`,
`SILInstruction::isDeallocatingStack`, etc), calling them (push and pop)
from a function which makes use the stack for dynamically sized
allocations can result in violations of stack discipline of the form
```
swift_task_alloc // allocates %ptr_1
copy_value_witness // copies into %ptr_1
swift_task_localValuePush // calls swift_task_alloc and allocates %ptr_2
swift_task_dealloc // deallocates %ptr_1
swift_task_localValuePop // calls swift_task_dealloc and deallocates %ptr_2
```
Avoid the problem by not allocating dynamically sized stack space in the
function which calls `_taskLocalValuePush` and `_taskLocalValuePop`.
Split the calls to those functions into `withValueImpl` function which
takes its argument `__owned`. Call that function from `withValue`,
ensuring that the necessary copy (to account for the fact that withValue
takes its argument `__guaranteed` but `_taskLocalValuePush` takes its
`__owned`) and associated stack traffic occur in `withValue`.
Still, allow `withValueImpl` to be inlined. The stack nesting will be
preserved across it.
rdar://107275872
In particular, the exactly internal layout of Array<> is quite
different between macOS and Linux, which makes it impractical
for use in tests like this. An empty class is still a reference
and doesn't introduce so many complications.
Follow-up to https://github.com/apple/swift/pull/65048
`getDesugaredType` unwraps sugar types that appear in sequence,
to remove sugar from nested positions we need to get a canonical type.
Thanks to @slavapestov for pointing it out.
Generic type aliases, unless desugared, could bring unrelated type variables
into the scope i.e. `TypeAlias<$T, $U>.Context` is actually `_Context<$U>`.
These variables could be inferrable only after the the body the closure is
solved. To avoid that, let's adjust `TypeVariableRefFinder` to desugar types
before collecting referenced type variables.
Resolves: rdar://107835060
