Even if the member type variable is partially resolved, we still need
to mark inner type variables (if any) as holes because they might not
be connected to anything that could provide contextual type(s).
Resolves: rdar://124549952
* Adds RangeSet/DiscontiguousSlice to the stdlib
* Remove redundant DiscontiguousSlice.Index: Comparable conformance
* Attempt to fix embedded build
* Attempt to fix macOS test failures
* Fix Constaints/members.swift failure on linux
* Add exceptions to ABI/source checker to fix macOS tests
* Fix incremental dependency test failure
* Remove inlining/unfreeze implementation for future improvements
* Simplify indices(where:) implementation
* Address review feedback
* Add test for underscored, public slice members
* Address feedback on inlining, hashing, and initializing with unordered arrays
* Fix ABI checker issues
* Remove MutableCollection extension for DiscontiguousSlice
* Make insertion return a discardable Bool
* Fix ABI checker tests
* Fix other ABI checker tests due to dropping MutableCollection subscript
Code like that is usually indicative of programmer error, and does not
round-trip through module interface files since there is no source
syntax to refer to an outer generic parameter.
For source compatibility this is a warning, but becomes an error with
-swift-version 6.
Fixes rdar://problem/108385980 and https://github.com/apple/swift/issues/62767.
Don't attempt the fix until sub-expression is resolved
if chain is not using leading-dot syntax. This is better
than attempting to propagate type information down
optional chain which is hard to diagnose.
Resolves: rdar://105348781
If base type of the leading-dot syntax expression has been determined
to be a placeholder, this could only mean that `.<name>` couldn't be
resolved in the current context.
Resolves: rdar://104302974
Most of the diagnostics for extra/missing/mislabeled arguments refer
to argument to a "call". Some (but not call) would substitute in
"subscript". None would refer to an argument to a macro expansion
properly.
Rework all of these to refer to the argument in a call, subscript, or
macro expansion as appropriate. Fix up lots of tests that now say
"subscript" instead, and add tests for macro expansions.
It is not the case that `any P` satisfies a class bound
even if the existential is a composition with an exact
match to the class bound. The resulting existential box
must be opened as the exact class type before this conversion
can succeed.
This appears to be a regression from Swift 5.1, which was the last
Swift compiler that banned this typing rule.
rdar://92358570
Restrict filtering in `simplifyAppliedOverloadsImpl` to disable
overload set for operators only, because other calls e.g. regular
functions or subscripts could be filtered on labels and are less
overloaded.
Filtering non-operator calls could also lead to incorrect diagnostics
because first choice could have all sorts of different issues e.g.
incorrect labels and number of parameters.
Resolves: rdar://55369704
If there are multiple overloads and all of them require explicit
base type for a member reference, let's diagnose it as a single
error since the problem is the same across the overload choices:
```swift
func foo<T>(_: T, defaultT: T? = nil) {}
func foo<U>(_: U, defaultU: U? = nil) {}
foo(.bar)
```
In this example there is not enough contextual information to
determine base type of `.bar` reference and hence both `foo`
overloads are a considered valid solutions until explicitly set
base type disambiguates them.
Resolves: rdar://problem/66891544
This adds the RangeSet and DiscontiguousSlice types, as well as collection
operations for working with discontiguous ranges of elements. This also adds
a COWLoggingArray type to the test suite to verify that mutable collection
algorithms don't perform unexpected copy-on-write operations when mutating
slices mid-operation.
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).
It might be either impossible to infer the base because there is
no contextual information e.g. `_ = .foo` or there is something
else wrong in the expression which disconnects member reference
from its context.
Patch up all the places that are making a syntactic judgement about the
isInvalid() bit in a ValueDecl. They may continue to use that query,
but most guard themselves on whether the interface type has been set.
This is an amalgam of simplifications to the way VarDecls are checked
and assigned interface types.
First, remove TypeCheckPattern's ability to assign the interface and
contextual types for a given var decl. Instead, replace it with the
notion of a "naming pattern". This is the pattern that semantically
binds a given VarDecl into scope, and whose type will be used to compute
the interface type. Note that not all VarDecls have a naming pattern
because they may not be canonical.
Second, remove VarDecl's separate contextual type member, and force the
contextual type to be computed the way it always was: by mapping the
interface type into the parent decl context.
Third, introduce a catch-all diagnostic to properly handle the change in
the way that circularity checking occurs. This is also motivated by
TypeCheckPattern not being principled about which parts of the AST it
chooses to invalidate, especially the parent pattern and naming patterns
for a given VarDecl. Once VarDecls are invalidated along with their
parent patterns, a large amount of this diagnostic churn can disappear.
Unfortunately, if this isn't here, we will fail to catch a number of
obviously circular cases and fail to emit a diagnostic.
Extend use of "instance member on type" fix to cover potentially
invalid partial applications, references to instance members on
metatypes, and remove related and now obsolete code from `CSDiag`.
Resolves: [SR-9415](https://bugs.swift.org/browse/SR-9415)
While computing a type of member via `getTypeOfMemberReference`
let's delay opening generic requirements associated with function
type until after self constraint has been created, that would give
a chance for contextual types to get propagated and make mismatch
originated in generic requirements much easier to diagnose.
Consider following example:
```swift
struct S<T> {}
extension S where T == Int {
func foo() {}
}
func test(_ s: S<String>) {
s.foo()
}
```
`foo` would get opened as `(S<$T>) -> () -> Void` and contextual `self`
type is going to be `S<String>`, so applying that before generic requirement
`$T == Int` would make sure that `$T` gets bound to a contextual
type of `String` and later fails requirement constraint `$T == Int`.
This is much easier to diagnose comparing to `$T` being bound to
`Int` right away due to same-type generic requirement and then
failing an attempt to convert `S<String>` to `S<Int>` while simplifying
self constraint.
Resolves: rdar://problem/46427500
Resolves: rdar://problem/34770265
This is useful for `CSDiag` when it detects that all
overload choices have the same problem. Since there
are going to be no solutions, choice declaration could
be supplied to `invalid ref` diagnostic directly.
Resolves: rdar://problem/50467583
Resolves: rdar://problem/50682022
Resolves: rdar://problem/50909555
TupleShuffleExpr could not express the full range of tuple conversions that
were accepted by the constraint solver; in particular, while it could re-order
elements or introduce and eliminate labels, it could not convert the tuple
element types to their supertypes.
This was the source of the annoying "cannot express tuple conversion"
diagnostic.
Replace TupleShuffleExpr with DestructureTupleExpr, which evaluates a
source expression of tuple type and binds its elements to OpaqueValueExprs.
The DestructureTupleExpr's result expression can then produce an arbitrary
value written in terms of these OpaqueValueExprs, as long as each
OpaqueValueExpr is used exactly once.
This is sufficient to express conversions such as (Int, Float) => (Int?, Any),
as well as the various cases that were already supported, such as
(x: Int, y: Float) => (y: Float, x: Int).
https://bugs.swift.org/browse/SR-2672, rdar://problem/12340004
This is a follow-up to https://github.com/apple/swift/pull/23194,
which broke a case were single local overload choice was preferred
over any number of outer alternatives.
This PR migrates instance member on type and type member on instance diagnostics handling to use the new diagnostics framework (fixes) and create more reliable and accurate diagnostics in such scenarios.
While attempting to form a call of an unresolved member, the fact
that argument application could fail has to be accounted for.
Resolves: rdar://problem/48114578
