This change makes us treat it exactly as we do 'init'. We don't allow renaming the base name,
and don't fail if the basename doesn't match for calls.
Also:
- explicit init calls/references like `MyType.init(42)` are now reported with
'init' as a keywordBase range, rather than nothing.
- cursor info no longer reports rename as available on init/callAsFunction
calls without arguments, as there's nothing to rename in that case.
- Improved detection of when a referenced function is a call (rather than
reference) across syntactic rename, cursor-info, and indexing.
Resolves rdar://problem/60340429
We already ban all structs from declaring storage that comes from implementation-only imports. Until now we missed property wrappers, they were just dropped in deserialization.
Resolves rdar://problem/59403617
Start visiting transitive fixed bindings for type
variables, and stop visiting adjacencies for
`gatherConstraint`'s `AllMentions` mode.
This improves performance and fixes a correctness
issue with the old implementation where we could
fail to re-activate a coercion constraint, and
then let invalid code get past Sema, causing
either miscompiles or crashes later down the
pipeline.
Unfortunately this change requires us to
temporarily drop the non-ephemeral fix for a couple
of fairly obscure cases where the overload hasn't
yet been resolved. The logic was previously relying
on stale adjacency state in order to re-activate
the fix when the overload is bound, but it's not
connected on the constraint graph. We need to find
a way to connect constraints to unresolved
overloads they depend on.
Resolves SR-12369.
wrapped value placeholder in an init(wrappedValue:) call that was previously
injected as an OpaqueValueExpr. This commit also restores the old design of
OpaqueValueExpr.
* In the DeclChecker, duplicate the check that we have a reasonable
RawValue type so we do not attempt to form an invalid key. The interface
to the autoincrementer has this as invariant, but it was not previously
checked as a precondition.
* In the deriver, try to check for the case where the user has written
a mismatched explicit declaration of RawValue, or a type sharing that
name, and check type equality with the declared raw type to make this
pass resilient to mismatches as well.
Resolves rdar://57072148, rdar://59703784
In order to allow this, I've had to rework the syntax of substituted function types; what was previously spelled `<T> in () -> T for <X>` is now spelled `@substituted <T> () -> T for <X>`. I think this is a nice improvement for readability, but it did require me to churn a lot of test cases.
Distinguishing the substitutions has two chief advantages over the existing representation. First, the semantics seem quite a bit clearer at use points; the `implicit` bit was very subtle and not always obvious how to use. More importantly, it allows the expression of generic function types that must satisfy a particular generic abstraction pattern, which was otherwise impossible to express.
As an example of the latter, consider the following protocol conformance:
```
protocol P { func foo() }
struct A<T> : P { func foo() {} }
```
The lowered signature of `P.foo` is `<Self: P> (@in_guaranteed Self) -> ()`. Without this change, the lowered signature of `A.foo`'s witness would be `<T> (@in_guaranteed A<T>) -> ()`, which does not preserve information about the conformance substitution in any useful way. With this change, the lowered signature of this witness could be `<T> @substituted <Self: P> (@in_guaranteed Self) -> () for <A<T>>`, which nicely preserves the exact substitutions which relate the witness to the requirement.
When we adopt this, it will both obviate the need for the special witness-table conformance field in SILFunctionType and make it far simpler for the SILOptimizer to devirtualize witness methods. This patch does not actually take that step, however; it merely makes it possible to do so.
As another piece of unfinished business, while `SILFunctionType::substGenericArgs()` conceptually ought to simply set the given substitutions as the invocation substitutions, that would disturb a number of places that expect that method to produce an unsubstituted type. This patch only set invocation arguments when the generic type is a substituted type, which we currently never produce in type-lowering.
My plan is to start by producing substituted function types for accessors. Accessors are an important case because the coroutine continuation function is essentially an implicit component of the function type which the current substitution rules simply erase the intended abstraction of. They're also used in narrower ways that should exercise less of the optimizer.
If constraint system is underconstrained e.g. because there are
editor placeholders, it's possible to end up with multiple solutions
where each ambiguous declaration is going to have its own overload kind:
```swift
func foo(_: Int) -> [Int] { ... }
func foo(_: Double) -> (result: String, count: Int) { ... }
_ = foo(<#arg#>).count
```
In this case solver would produce 2 solutions: one where `count`
is a property reference on `[Int]` and another one is tuple access
for a `count:` element.
Resolves: rdar://problem/49712598
Currently constraint solver is only capable of detecting universally unavailable
overloads but that's insufficient because it's still possible to pick a contextually
unavailable overload choice which could be better than e.g. generic overload, or
one with defaulted arguments, marked as disfavored etc.
Let's introduce `ConstraintSystem::isDeclUnavailable` which supports both universal
and contextual unavailability and allow constraint solver to rank all unavailable
overload choices lower than any other possible choice(s).
Resolves: rdar://problem/59056638
Don't attempt to figure out what exactly is ambiguous, let
`diagnoseAmbiguity` take care of that. Simplify make sure
that only some of the solutions have fixes and these fixes
are all related to use of ephemeral pointers.
It's done by first retrieving all generic parameters from each solution,
filtering boundings into distrinct set and diagnosing any differences.
For example:
```swift
func foo<T>(_: T, _: T) {}
func bar(x: Int, y: Float) {
foo(x, y)
}
```
As part of this, we have to change the type export rules to
prevent `@convention(c)` function types from being used in
exported interfaces if they aren't serializable. This is a
more conservative version of the original rule I had, which
was to import such function-pointer types as opaque pointers.
That rule would've completely prevented importing function-pointer
types defined in bridging headers and so simply doesn't work,
so we're left trying to catch the unsupportable cases
retroactively. This has the unfortunate consequence that we
can't necessarily serialize the internal state of the compiler,
but that was already true due to normal type uses of aggregate
types from bridging headers; if we can teach the compiler to
reliably serialize such types, we should be able to use the
same mechanisms for function types.
This PR doesn't flip the switch to use Clang function types
by default, so many of the clang-function-type-serialization
FIXMEs are still in place.
Stop filtering outer overload choices while trying to pre-check
expression, instead have it always fetch those and use new
fix to only attempt them in diagnostic mode (unless it's min/max
situation with conditional conformances).
When wrapping a function which is supposed to capture the caller’s location, there’s always a risk that the wrapper won’t capture the information the wrapped function wants; for instance, you might pass `(…, line, column)` where the callee expected `(…, column, line)`.
This commit emits a warning when a call passes an explicit argument to something that has a default argument, and that explicit argument is itself a parameter with a default argument, and both parameters use magic identifiers, but they use *different* magic identifiers. This is partially in support of concise #file, but applies to all magic identifiers.
Fixes rdar://problem/58588633.
The error recovery logic around derived conformances is a little bit
tricky. Make sure we don't crash if a type explicitly provides a
RawValue type witness that is not equatable, but omits the witnesses
for init(rawValue:) and the rawValue property.
Fixes <rdar://problem/58127114>.
