Commit Graph

64 Commits

Author SHA1 Message Date
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