Slava Pestov
dd3e49c3ac
Sema: Remove one-way constraint handling from computeConnectedComponents()
2024-12-21 00:42:13 -08:00
Slava Pestov
385d66f24e
Sema: Remove ConstraintKind::OneWayEqual
2024-12-21 00:42:13 -08:00
Slava Pestov
bb55d9c59a
Sema: Remove -experimental-one-way-closure-params
2024-12-19 13:14:11 -05:00
Pavel Yaskevich
1760bd1f1e
[CSOptimizer] Remove an outdated optimization to compare resolved argument types with all else equal
...
This is already accounted for by `determineBestChoicesInContext`
and reflected in the overall score, which means that we no longer
need to use this in vacuum.
2024-12-17 11:36:39 -08:00
Hamish Knight
73fb36f371
[AST] Split out "is compound" bit on FunctionRefInfo
...
FunctionRefKind was originally designed to represent
the handling needed for argument labels on function
references, in which the unapplied and compound cases
are effectively the same. However it has since been
adopted in a bunch of other places where the
spelling of the function reference is entirely
orthogonal to the application level.
Split out the application level from the
"is compound" bit. Should be NFC. I've left some
FIXMEs for non-NFC changes that I'll address in a
follow-up.
2024-12-02 14:11:33 +00:00
Hamish Knight
a4d51419ba
[AST] NFC: Rename FunctionRefKind -> FunctionRefInfo
2024-12-02 14:11:32 +00:00
Slava Pestov
3400022c63
Sema: Remove ConstraintKind::SelfObjectOfProtocol
2024-10-22 20:14:43 -04:00
Slava Pestov
b44bff26b5
Sema: Fold Constraint::createFixedChoice() into Constraint::createBindOverload()
2024-10-22 20:14:42 -04:00
Slava Pestov
2eaec5a97f
Sema: Remove Constraint::clone()
2024-10-22 20:14:42 -04:00
Slava Pestov
0de8428f34
Sema: Tail-allocate Constraint::Overload::Choice
...
OverloadChoice is rather large, 40 bytes.
2024-10-22 20:14:42 -04:00
Slava Pestov
a48591d71d
Sema: Tail-allocate Constraint::TheFix
...
Most constraints don't have a fix, so we can tail-allocate the fix.
This saves 16 bytes per constraint, because it also eliminates some
padding.
2024-10-22 20:14:42 -04:00
Pavel Yaskevich
5a93255133
[ConstraintSystem] Introduce new LValueObject constraint
2024-08-29 10:10:14 -07:00
Ben Barham
ef8825bfe6
Migrate llvm::Optional to std::optional
...
LLVM has removed llvm::Optional, move over to std::optional. Also
clang-format to fix up all the renamed #includes.
2024-02-21 11:20:06 -08:00
Sima Nerush
7aa3c26bec
[Docs] Add details for addMaterializePackExpansionConstraint
2023-12-25 11:57:55 -08:00
Hamish Knight
a64ba23d7b
[CS] NFC: Store ContextualTypeInfo in SyntacticElementTarget
...
Move the contextual type locator onto
ContextualTypeInfo, and consolidate the separate
fields in SyntacticElementTarget into storing a
ContextualTypeInfo. This then lets us plumb down
the locator for the branch contextual type of an
if/switch expression from the initial constraint
generation, rather than introducing it later. This
should be NFC.
2023-07-26 16:46:54 +01:00
Sophia Poirier
fa41015ae4
[ConstraintSystem] implement implicit pack materialization for abstract tuples instead of explicit '.element'
2023-07-14 10:32:38 -07:00
Evan Wilde
f3ff561c6f
[NFC] add llvm namespace to Optional and None
...
This is phase-1 of switching from llvm::Optional to std::optional in the
next rebranch. llvm::Optional was removed from upstream LLVM, so we need
to migrate off rather soon. On Darwin, std::optional, and llvm::Optional
have the same layout, so we don't need to be as concerned about ABI
beyond the name mangling. `llvm::Optional` is only returned from one
function in
```
getStandardTypeSubst(StringRef TypeName,
bool allowConcurrencyManglings);
```
It's the return value, so it should not impact the mangling of the
function, and the layout is the same as `std::optional`, so it should be
mostly okay. This function doesn't appear to have users, and the ABI was
already broken 2 years ago for concurrency and no one seemed to notice
so this should be "okay".
I'm doing the migration incrementally so that folks working on main can
cherry-pick back to the release/5.9 branch. Once 5.9 is done and locked
away, then we can go through and finish the replacement. Since `None`
and `Optional` show up in contexts where they are not `llvm::None` and
`llvm::Optional`, I'm preparing the work now by going through and
removing the namespace unwrapping and making the `llvm` namespace
explicit. This should make it fairly mechanical to go through and
replace llvm::Optional with std::optional, and llvm::None with
std::nullopt. It's also a change that can be brought onto the
release/5.9 with minimal impact. This should be an NFC change.
2023-06-27 09:03:52 -07:00
Pavel Yaskevich
2ee646f47b
[ConstraintSystem] NFC: Generalize DefaultClosureType constraint
...
This constraint is useful in more places than closures because
it gives a way to provide a "fallback type" without it having
effect on inference.
2023-06-16 11:15:15 -07:00
Pavel Yaskevich
fdfedc62bd
[ConstraintSystem] NFC: Reverse direction of ShapeOf constraint
...
First type is the reduced shape of the second type (the pack type).
2023-05-03 10:44:10 -07:00
Pavel Yaskevich
bbe305cd43
[ConstraintSystem] Add same-shape constraint
...
The constraint takes two pack types and makes sure that their
reduced shapes are equal. This helps with diagnostics because
constraint has access to the original pack expansion pattern
types.
2023-05-02 09:32:19 -07:00
Pavel Yaskevich
438ee330f1
[ConstraintSystem] Add new conversion kind - ArrayToCPointer
...
It's `ArrayToPointer` conversion that has PointerToCPointer
semantics for (un-)signed integer element types.
2023-03-14 11:22:52 -07:00
Doug Gregor
8adee85cb6
[Macros] Add support for explicit generic arguments of macros.
...
Enable type checking support for explicitly specifying generic arguments to
a macro, e.g., `#stringify<Double>(1 + 2)`. To do so, introduce a new
kind of constraint that performs explicit argument matching against the
generic parameters of a macro only after the overload is chosen.
2022-11-28 18:32:43 -08:00
Slava Pestov
731d903a43
Sema: Add ConstraintKind::ShapeOf
2022-10-25 12:55:04 -04:00
Holly Borla
032c511754
[ConstraintSystem] Add a PackElementOf constraint to delay mapping opened
...
element pattern types to pattern archetypes until after type variables are
resolved.
2022-10-24 19:46:44 -07:00
Slava Pestov
46d5fa68f9
Sema: Introduce ConstraintKind::SubclassOf
2022-10-21 22:17:38 -04:00
Holly Borla
67fb143f0e
[AST] Remove ReifyPackExpr.
2022-10-10 16:25:26 -07:00
Pavel Yaskevich
164fa9c45d
Revert "[ConstraintSystem] NFC: Remove obsolete ValueWitness constraint"
...
This reverts commit ef0523fe29 .
2022-09-14 11:35:27 -07:00
Amritpan Kaur
64800d576e
[Constraint] Pass solverState indents to ASTPrinter's dump so that AST printed during conjunction attempts are indented correctly.
2022-07-21 13:34:22 -07:00
Amritpan Kaur
f3dd7f68a8
[Constraint] Eliminate repetitive locators to make useful information easier to read.
2022-07-05 14:20:08 -07:00
Pavel Yaskevich
ef0523fe29
[ConstraintSystem] NFC: Remove obsolete ValueWitness constraint
2022-05-30 23:17:41 -07:00
Pavel Yaskevich
0a5b3f0727
[TypeChecker] SE-0324: Extend Swift -> C pointer conversions to inout
...
Fixes an oversight where `inout` -> C pointer conversion wasn't covered
by implementation of new pointer conversion semantics proposed by SE-0324.
Resolves: rdar://92583588
2022-05-25 20:55:22 -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
Robert Widmann
d44d8ec043
Allow Converting Pack Types to Tuples
...
Insert an implicit conversion from pack types to tuples with equivalent parallel structure. That means
1) The tuple must have the same arity
2) The tuple may not have any argument labels
3) The tuple may not have any variadic or inout components
4) The tuple must have the same element types as the pack
2021-12-16 08:51:38 -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
Hamish Knight
237338b504
Merge pull request #40224 from hamishknight/super-tuple-shuffle
2021-11-18 09:50:09 +00:00
Hamish Knight
da36a2cb88
[CS] Restore a type variable for compatibility with rdar://85263844
...
Despite being otherwise disconnected from the
constraint system, it's possible for it to affect
how we type-check tuple matches in certain cases.
This is due to the fact that:
- It can have a lower type variable ID than an
opened generic parameter type, so becomes the
representative when merged with it. And because it
has a different locator, this can influence
binding prioritization.
- Tuple subtyping is broken, as it's currently a
*weaker* relationship than conversion.
Therefore, temporarily restore this bit of logic
for language versions < 6. If possible, we should
try and fix tuple subtying in Swift 6 mode to not
accept label mismatches, so that it's not more
permissive than tuple conversion.
rdar://85263844
2021-11-17 17:06:19 +00:00
Pavel Yaskevich
3927f56dbd
[ConstraintSystem] Warn about discarded expressions found in multi-statement closures
2021-11-15 16:42:04 -08:00
Hamish Knight
b8e4c676c6
[CS] Remove function component constraints
...
FunctionInput relies on being able to represent
parameter lists as tuples, which won't be possible
once parameter flags are stripped from tuple types.
FunctionResult is reasonable, but is currently
unused.
2021-10-12 09:51:45 +01: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
55bae6150d
[Constraint] Allow closure body elements to carry contextual information
2021-10-08 10:08:02 -07:00
Pavel Yaskevich
9073d00613
[ConstraintSystem] Allow conjunctions marking conjunctions as isolated from the rest of the system
2021-10-08 10:08:01 -07:00
Pavel Yaskevich
ad01027a0d
[ConstraintSystem] Allow closure body element constraint to reference type variables
...
This would be useful when once it's used as part of a conjunction to
be able to solve the closure body element component in isolation.
2021-10-08 10:08:01 -07:00
Pavel Yaskevich
73dffb3125
[ConstraintSystem] Don't require a type variable per closure body element
...
Since each of the body elements is already going to have a type associated
with it there is no need to create yet another type variable.
2021-10-08 10:08:01 -07:00
Pavel Yaskevich
6aaee599bd
[ConstraintSystem] Allow conjunction constraints to reference other variables
2021-10-08 10:08:00 -07:00
Pavel Yaskevich
2b4691048e
[ConstraintSystem] Add a skeleton of Conjunction constraint
...
It's similar to disjunction constraint but represents an "and"
relationship between its elements instead of "or", so all of the
elements have to produce a solution for conjunction constraint
to be considered solved successfully.
2021-10-08 10:08:00 -07:00
Pavel Yaskevich
eb8eabfba7
[ConstraintSystem] Add a skeleton of ClosureBodyElement constraint
2021-10-08 10:08:00 -07:00
Pavel Yaskevich
9e7a670295
[ConstraintSystem] Implement new Swift -> C pointer conversions
...
Allow following conversions in argument positions
(applies only to call to imported C/ObjC declarations):
- Unsafe[Mutable]RawPointer -> Unsafe[Mutable]Pointer<[U]Int>
- Unsafe[Mutable]Pointer<Int{8, 16, ...}> <-> Unsafe[Mutable]Pointer<UInt{8, 16, ...}>
2021-09-20 17:22:25 -07:00
Pavel Yaskevich
3a41f7af5f
[ConstraintSystem] Add a new conversion - Swift to C pointers
...
Following pointer conversions are supported in argument positions (when referencing C/ObjC functions):
- Unsafe[Mutable]RawPointer -> Unsafe[Mutable]Pointer<[U]Int>
- Unsafe[Mutable]Pointer<Int{8, 16, ...}> -> Unsafe[Mutable]Pointer<UInt{8, 16, ...}>
2021-09-20 17:22:25 -07:00