In some situations `getContextualType` for a contextual type
locator is going to return then empty type. This happens because
e.g. optional-some patterns and patterns with incorrect type don't
have a contextual type for initialization expression but use
a conversion with contextual locator nevertheless to indicate
the purpose. This doesn't affect non-ambiguity diagnostics
because mismatches carry both `from` and `to` types.
Resolves: rdar://problem/103739206
All of the type variables referenced by a type had to be
handled by `inferVariables` otherwise it would to possible
to bring non-representative variable into scope which in
turn later would get simplied into a variable that doesn't
exist in the active scope and solver would crash.
Resolves: rdar://83418797
Currently solver picks the first conjunction it can find,
which means - the earliest resolved closure. This is not
always correct because when calls are chained closures
passed to the lower members could be resolved sooner
than the ones higher up but at the same time they depend
on types inferred from members higher in the chain.
Let's make sure that multi-statement closures are always
solved in order they appear in the AST to make sure that
types are available to members lower in the chain.
SE-0110 allows tuple slat between function types. The solver needs to
account for that when trying to infer parameter types from context
while resolving a closure in order to propagate types and speed up
type-checking.
Resolves: https://github.com/apple/swift/issues/62390
getContextSubstitutionMap() builds a substitution map for the generic signature of
the parent context, which is wrong if the typealias has its own 'where' clause.
Inject `buildBlock` call into `return`, `buildFinalResult`, and
`build{Optional, Either}` to take advantage of contextual information
and maintain compatibility with current inference behavior.
Invalid syntax could introduce type variables into sequence which
have to be brought into scope otherwise solver is going to crash.
Resolves: rdar://100753270
If a (partial) solution has a type variable it could only be unbound
if `FreeTypeVariableBinding` is set to `Allow`, in all other cases
solution would either have a fully resolved type or a hole.
`applySolution` shouldn't second guess `finalize()` and just apply
a solution as given. This is very important for multi-statement closures
because their elements are solved in isolation and opaque value types
inferred for their result could contain not-yet-resolved type variables
from outer context in their substitution maps (which it totally legal
under bi-directional inference).
Bools are special in that they only need 1 bit of storage, and have many
extra inhabitants available. This adds a test to check that an optional
whose payload is a bool is reflected correctly.
There are certain protocol method decls types that swift does not import
today.
```
@protocol Incomplete
- (id)getObjectFromVarArgs:(id)first, ...;
@end
```
Furthermore, the old method also emitted duplicate entries for protocols
methods when Swift synthesized methods for diagnosics.
We won't import this method into Swift. So if we emit protocol metadata
from swift delcs we would generate incomplete records.
rdar://60888524
We can end up with a stack overflow if we encounter a very deeply nested type, or bad data that looks like one. Fail gracefully for types that are nested beyond a limit. By default, the limit is 50.
rdar://100847548
* Backdeploy swift_task_future_wait
This patch adds the implementation for `swift_task_future_wait`
entrypoint to the backdeploy library.
This involves pulling in `AsyncTask::waitFuture`, which relies on a fair
bit.
Please note, this pulls in the `StaticMutex` implementation from Swift
5.6. There are some challenges here. The concurrency version of the
`StaticMutex` involves a fairly nasty set of ODR violations in the
normal setup. See `public/Concurrency/Mutex.cpp`, which includes the
Mutex implementations cpp files directly, while defining a single macro
to replace the implementation of swift::fatalError with
swift_concurrency_fatalError. We only need the concurrency mutex (at
least for now), so I have hard-coded the `swift_concurrency_fatalError`
version into this library. If we should need the other implementation,
we are forced to include ODR-related undefined behavior.
We need symbols from C++, so I've added an implicit linker flag whenever
the static library is used, namely, it passes `-lc++` to the linker.
Since we only backdeploy on Apple platforms, this should be fine.
Some of the platform runtimes we need to backdeploy to have the
enter/exitThreadLocalContext functions defined, while others don't. We
define our own backdeploy56 shim function that dlsym's the function
pointer for these symbols if we have exclusivity checking available.
Otherwise, it doesn't do anything. If concurrency exclusivity checking
is available, we'll use it, otherwise we wont'.
The same dlsym check is done for `swift_task_escalate`. Not all
platforms we need to backdeploy to have a concurrency runtime. The
symbols that do need to use pieces of the concurrency runtime should not
be getting hit when deploying to systems that don't have concurrency. In
the event that you've gotten around the language blocking you from
calling these symbols and you've managed to call concurrency pieces
without using concurrency, we'll abort because something is seriously
wrong.
* Backdeploy swift_task_future_wait_throwing
Drop the remaining pieces in for adding
`swift_task_future_wait_throwing`.
* Apply task_wait_future fix
Actually apply the fix from ef80a315f8.
This deviates slightly from the original patch.
AsyncTask::PrivateStorage::_Status() does not exist in the Swift 5.6
library. Instead I am using `AsyncTask::PrivateStorage::Status`.
* Workaround missing compiler-rt linking
Working around the missing link against compiler-rt in these test.
They are a bit brittle as if anything in them uses compiler-rt, they
will start failing. The backdeploy 5.6 library uses some symbols from
compiler-rt, thus causes them to fail to link.
Disabling the runtime compatibility version checking to avoid these
symbols. This should be fine for the MicroStdlib test, but we should fix
'%target-ld' to handle this better in the future.
rdar://100868842
