averello/swift-mirror
1
0
Fork 0
mirror of https://github.com/apple/swift.git synced 2025-12-14 20:36:38 +01:00
Code Issues Packages Projects Releases Wiki Activity
137,261 Commits 622 Branches 2,942 Tags
f6cdcc736dde25aff22e80d84eb7533a78b31b8c
Commit Graph

95 Commits

Author SHA1 Message Date
Pavel Yaskevich
569333135c Merge pull request #58768 from xedin/redecl-check-in-multi-closures 
[CSClosure] Diagnose invalid re-declarations in multi-statement closures
 2022-05-18 15:03:41 -07:00
Pavel Yaskevich
f210442913 [CSClosure] Anchor for-in sequence constraints on sequence expression 
This was an incorrect locator since constraints do belong to a sequence
expression and not to a contextual pattern.
 2022-05-18 00:32:20 -07:00
Pavel Yaskevich
854f64eff5 [CSClosure] Diagnose invalid re-declarations in multi-statement closures 
Calling `typeCheckDecl` on `VarDecl` is what triggers re-declaration
checking and that was skipped by the solution application logic.
 2022-05-09 12:50:39 -07:00
Pavel Yaskevich
67895c2927 [CSClosure] Mark partially inferred external declarations as invalid 
If a syntactic element references an external declaration (relative
to its own context), let's check whether it has any type variables,
and if so, replace them with errors to remove any possibility of
bringing external constraints into element's scope.

Resolves: rdar://92347054
 2022-05-05 11:44:26 -07:00
Pavel Yaskevich
a282aaa447 [CSClosure] Rename closure solution application and switch to AnyFunctionRef 
Closure solution application has been renamed to `SyntacticElementSolutionApplication`
and can now handle both closure and function bodies.
 2022-04-26 13:54:48 -07:00
Pavel Yaskevich
e8013423c8 [CSClosure] Rename closure constraint generator and switch to AnyFunctionRef 
Closure constraint generator has been renamed to `SyntacticElementGenerator`
and can now handle both closure and function bodies.
 2022-04-26 10:12:15 -07:00
Pavel Yaskevich
6a65810d30 [Constraint] NFC: Rename ClosureBodyElement to SyntacticElement 
`SyntacticElement` represents a statement, pattern, declaration,
condition, or expression and could originate from i.e. a closure,
a function or a result builder body.
 2022-04-26 09:55:04 -07:00
Josh Soref
4c77c59269 Spelling sema (#42474) 
* spelling: accessibility

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: accessories

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: adjustments

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: all

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: ambiguous

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: arguments

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: assignment

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: associated

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: assumes

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: auxiliary

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: availability

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: available

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: belongs

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: checking

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: clazz

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: compatibility

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: completely

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: completion

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: complicated

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: conformance

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: constrained

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: constraint

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: contextual

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: conversion

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: convertible

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: couldn't

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: declaration

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: defaultable

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: dependent

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: depending

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: describe

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: diagnostic

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: diagnostics

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: existential

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: expects

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: explicit

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: explicitly

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: expression

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: first

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: font

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: forward

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: generation

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: generic

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: given

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: global

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: guarantee

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: happened

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: hierarchy

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: identical

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: immediately

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: implicit

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: indicates

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: inferred

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: initialization

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: initialize

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: initializer

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: integrity

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: interpolation

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: introducing

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: involved

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: just

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: like

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: likewise

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: mismatch

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: missing

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: more

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: necessarily

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: noescape

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: nonetheless

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: occurrences

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: operators

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: optional

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: otherwise

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: outside

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: overload

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: overridden

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: override

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: parameter

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: parameters

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: penalize

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: platforms

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: precedence

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: preemptively

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: preliminary

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: preserve

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: propagate

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: propagated

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: qualifier

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: question

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: really

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: received

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: references

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: replaceable

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: replacement

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: representable

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: representative

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: requirement

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: requires

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: resolved

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: retrieve

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: rewriting

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: satisfied

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: semantics

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: signature

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: similar

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: simplest

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: simplification

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: solver

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: struct

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: structurally

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: success

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: sure

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: symmetric

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: syntactically

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: target

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: that

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: the

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: themselves

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: these

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: this

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: transform

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: transparent

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: tread

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: truncation

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: type

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: unconstructable

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: universally

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: unknown

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: unwrapped

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: versioned

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: visible

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: where

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

Co-authored-by: Josh Soref <jsoref@users.noreply.github.com>
 2022-04-20 15:12:46 -07:00
Pavel Yaskevich
869a413aae [CSClosure] Handle wrapped variables without explicit initializers 
All variables without explicit initializers were considered to be
uninitialized which is incorrect because if a variable has a property
wrapper attached to it that wrapper needs its initializer type-checked,
for example:

```
@propertyWrapper
struct Wrapper {
  var name: String

  ...
}

test {
  @wrapper(name: "wrapper")
  var v;
}
```

`v` gets initialized via a call to `Wrapper(name: "wrapper")`.

Resolves: rdar://91225620
 2022-04-06 14:36:31 -07:00
Pavel Yaskevich
df549dbdb3 [TypeChecker] SE-0326: Check whether function declaration is a result builder context 
This is a follow-up to https://github.com/apple/swift/pull/40708 which only considers
closures, but it missed the case when builder is applied to function body - in such
cases the declaration context is going to be a function/getter declaration.

Resolves: rdar://91150414
 2022-04-04 01:13:46 -07:00
Doug Gregor
4db1f7d4e7 Map case variable types out of context. 
Otherwise, we end up recording contextual types here.
 2022-03-28 11:06:50 -07:00
Pavel Yaskevich
d045598c14 Merge pull request #41892 from xedin/remove-last-uses-of-one-way 
[CSClosure] Remove last remaining uses of one-way constraints
 2022-03-24 10:42:28 -07:00
Pavel Yaskevich
ab46abb8ed [CSClosure] Remove last remaining uses of one-way constraints 
Removes uses of one-way constraint from for-in conditions and
case patterns which are solved via conjunctions.
 2022-03-18 10:42:33 -07:00
Alex Hoppen
f538d33e5f [CodeCompletion][Sema] Migrate CallArgurment position completion to the solver-based implementation 
This hooks up call argument position completion to the typeCheckForCodeCompletion API to generate completions from all the solutions the constraint solver produces (even those requiring fixes), rather than relying on a single solution being applied to the AST (if any).

Co-authored-by: Nathan Hawes <nathan.john.hawes@gmail.com>
 2022-03-17 15:15:54 +01:00
Pavel Yaskevich
5c3fb222e1 [CSClosure] Explode pattern binding declarations into conjunctions 
`one-way` constraints disable some optimizations related to component
selection because they imply strict ordering. This is a problem for
multi-statement closures because variable declarations could involve
complex operator expressions that rely on aforementioned optimizations.

In order to fix that, let's move away from solving whole pattern binding
declaration into scheme that explodes such declarations into indvidual
elements and inlines them into a conjunction.

For example:

```
let x = 42, y = x + 1, z = (x, test())
```

Would result in a conjunction of three elements:

```
x = 42
y = x + 1
z = (x, test())
```

Each element is solved indepedently, which eliminates the need for
`one-way` constraints and re-enables component selection optimizations.
 2022-03-08 21:37:40 -08:00
Pavel Yaskevich
e9f7a6a8f5 [CSClosure] Delay type-checking of local functions until body is rewritten 
A local function can capture a variable that has been declared after it,
which means that type-checking such declaration in-order would trigger
sub-typecheck that would corrupt AST underness the solution application
walker.
 2022-03-02 16:37:12 -08:00
Pavel Yaskevich
0cc8bc7928 [CSClosure] SE-0326: Type-checker statement conditions individually 
Instead of referencing whole statement condition, break it down to
individual elements and solve them separately.

Resolves: rdar://88720312
 2022-02-12 10:01:58 -08:00
Holly Borla
6cee193fc0 [Type System] When explicit existential types are enabled, wrap Error 
in ExistentialType for the type of error values.
 2022-01-13 19:30:44 -08:00
Pavel Yaskevich
b0dc6ece83 [CSClosure] Turn unreachability check into an assert for statements 
These are just invariant checks which will become obsolete as soon
as multi-statement closure inference is enabled by default.
 2021-12-26 20:25:13 -08:00
Pavel Yaskevich
35c24bc200 [ConstraintSystem] Make it possible to determine that closure is in result builder context 2021-12-25 17:07:55 -08:00
Pavel Yaskevich
f287f7e6e4 [CSClosure] Support empty return when closure result is optional Void 
Source compatibility workaround.

func test<T>(_: () -> T?) {
  ...
}

A multi-statement closure passed to `test` that has an optional
`Void` result type inferred from the body allows:
  - empty `return`(s);
  - to skip `return nil` or `return ()` at the end.

Implicit `return ()` has to be inserted as the last element
of the body if there is none. This wasn't needed before SE-0326
because result type was (incorrectly) inferred as `Void` due to
the body being skipped.

Resolves: rdar://85840941
 2021-12-08 13:27:21 -08:00
Pavel Yaskevich
5700516f2d [CSClosure] Make sure that body is always updated after solution application 
It's possible that solution application either modifies or replaces the
`BraceStmt` that represents closure body, so we need to make sure that
body is always updated.
 2021-12-08 11:58:30 -08:00
Pavel Yaskevich
9bd603bfc9 [Diagnostics] Apply "unhandled throw" diagnostic for for-in loop in closures 
Extract diagnostic into a method and use it while type-checking
`for-in` in top-level code and in closures.
 2021-12-03 10:56:32 -08:00
Pavel Yaskevich
248316536b [CSClosure] Warn about defer being the last element in the closure body 2021-12-03 10:56:07 -08:00
Pavel Yaskevich
0e6e058e7c [TypeChecker] Fix constraint solver to respect LeaveClosureBodyUnchecked flag 2021-12-03 10:54:07 -08:00
Pavel Yaskevich
46ff410a23 [ConstraintSystem] Warn about discarded expressions found in multi-statement closures 2021-12-03 10:53:50 -08:00
Pavel Yaskevich
bc54bc6bb7 Revert "[TypeChecker] SE-0326: Enable multi-statement closure inference by default" 2021-11-29 17:26:08 -08:00
Pavel Yaskevich
7b0f68c05f [Diagnostics] Apply "unhandled throw" diagnostic for for-in loop in closures 
Extract diagnostic into a method and use it while type-checking
`for-in` in top-level code and in closures.
 2021-11-15 16:42:05 -08:00
Pavel Yaskevich
8d1aeacc06 [CSClosure] Warn about defer being the last element in the closure body 2021-11-15 16:42:05 -08:00
Pavel Yaskevich
83033198c3 [TypeChecker] Fix constraint solver to respect LeaveClosureBodyUnchecked flag 2021-11-15 16:42:05 -08:00
Pavel Yaskevich
3927f56dbd [ConstraintSystem] Warn about discarded expressions found in multi-statement closures 2021-11-15 16:42:04 -08:00
Doug Gregor
45824befd2 Infer 'isolated' closure parameters from context. 
When a closure is provided with a contextual type that has isolated
parameters, infer that the corresponding closure parameter is "isolated".

Fixes rdar://83732479.
 2021-10-20 21:51:42 -07:00
Pavel Yaskevich
b865a7a451 [CSClosure] NFC: Remove outdated FIXME about SolutionApplicationTarget 2021-10-11 10:28:34 -07:00
Pavel Yaskevich
87f41a9b21 [CSClosure] Check multi-statement closure attrs only in if inference is enabled 2021-10-08 12:12:44 -07:00
Pavel Yaskevich
18b23aa50f [CSClosure] NFC: Add size to a SmallVector in ClosureConstraintGenerator::visitIfStmt 2021-10-08 10:08:04 -07:00
Pavel Yaskevich
b8cfaf778e [CSClosure] Make sure that partially resolved params/result gets their type variables referenced 
It's possible to declare explicit parameter/result type without
providing generic arguments, in such situation they'd be "opened"
as type variables and inferred from the contextual type or the body.

Type variable collector needs to account for that and include
such inner type variables into scope of an isolated closure.
 2021-10-08 10:08:04 -07:00
Pavel Yaskevich
e5db01b77d [CSClosure] Make sure that case body variables get types 
Solution application needs to set interface types for variables
declared in a case statement, otherwise this would lead to crashes
in SILGen.
 2021-10-08 10:08:04 -07:00
Pavel Yaskevich
b7b492ffd4 [CSClosure] Check parameters after solution is applied to the body of a closure 2021-10-08 10:08:03 -07:00
Pavel Yaskevich
50af68dca6 [CSClosure] Handle pattern and sequence of for-in loop together 
Let `visitForEachPattern` handle both pattern and the sequence
expression associated with `for-in` loop because types in this
situation flow in both directions:

- From pattern to sequence, informing its element type e.g.
  `for i: Int8 in 0 ..< 8`

- From sequence to pattern, when pattern has no type information.
 2021-10-08 10:08:03 -07:00
Pavel Yaskevich
29ec113d59 [CSClosures] Model return statements as solution application targets 
Each return statement gets a contextual type from outer context,
so the best model for that is via solution application target.
 2021-10-08 10:08:03 -07:00
Pavel Yaskevich
1dd76d83c6 [CSClosure] Avoid function conversion when closure result type is optional Void 
In cases like:

```
func test<T>(_: () -> T?) -> [T] {
   ...
}

test {
  if ... {
     return
  }

  ...
}
```

Contextual return type would be first attempted as optional and
then unwrapped if the first attempt did not succeed. To avoid having
to solve the closure twice (which results in an implicit function conversion),
let's add an implicit empty tuple (`()`) to the `return` statement
and allow it be to injected into optional as many times as context
requires.
 2021-10-08 10:08:03 -07:00
Pavel Yaskevich
bc14f00fe5 [CSClosure] Link closure conjunction with referenced outer parameters 
If one or more outer closure parameters used in the body of an
inner closure have not been resolved when conjunction is created,
let's reference them in the conjunction constraint to avoid
disconnecting conjunction from its context.
 2021-10-08 10:08:03 -07:00
Pavel Yaskevich
dfe6c3467f [CSClosure] Avoid creating conjunctions for empty bodies 2021-10-08 10:08:03 -07:00
Pavel Yaskevich
67a721485f [ConstraintSystem] Compute variables referenced by conjunction elements incrementally 
Attempting to pre-compute a set of referenced type variables
upfront is incorrect because parameter(s) and/or result type
could be bound before conjunction is attempted. Let's compute
a set of referenced variables before each element gets attempted.
 2021-10-08 10:08:03 -07:00
Pavel Yaskevich
fed705ddce [CSClosure] Account for partially resolved inner parameter types 
It is possible that contextual type of a parameter
has been assigned to an anonymous of named argument
early, to facilitate closure type checking. Such a
type can have type variables inside e.g.

```swift
func test<T>(_: (UnsafePointer<T>) -> Void) {}

test { ptr in
  ...
}
```

Type variable representing `ptr` in the body of
this closure would be bound to `UnsafePointer<$T>`
in this case, where `$T` is a type variable for a
generic parameter `T`.
 2021-10-08 10:08:03 -07:00
Pavel Yaskevich
8867a8d407 [CSApply] Delay solution application to multi-statement closure bodies 
Let's delay solution application to multi-statement closure bodies,
because declarations found in the body of such closures may depend
on its `ExtInfo` flags e.g. no-escape is set based on parameter if
closure is used in a call.
 2021-10-08 10:08:03 -07:00
Pavel Yaskevich
598b85006d [CSClosure] Allow all declarations to use typeCheckDecl 
This is necessary to ensure that all of the information is
properly materialized, and access/availability and other
required checks are performed.
 2021-10-08 10:08:03 -07:00
Pavel Yaskevich
fba80888ad [CSClosure] Mark conjunctions representing closure body as isolated 
Bodies of multi-statement closures should be handled in isolation
because they don't dependent on anything expect parameter/result
types from outer context.
 2021-10-08 10:08:03 -07:00
Pavel Yaskevich
ff4aca308d [ConstraintSystem/Closures] Ignore all unsupported declarations during constraint generation 
Everything besides `PatternBindingDecl` is handled at solution application time.
 2021-10-08 10:08:03 -07:00
Pavel Yaskevich
c68a74a0c6 [ConstraintSystem/Closures] Allow return without result expression 2021-10-08 10:08:02 -07:00