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
Currently ambiguity notes attached to a candidate only mention
expected type and its position. To improve clarify of such notes
it's useful to print argument type as well since it's not always
clear what it is at the first glance at the code.
Resolves: SR-14634
Resolves: rdar://78224323
In situations like:
$T0 subtype $T1
$T1 literal conforms to ExpressibleByArrayLiteral
$T0 conv [<Type>]?
We have to ensure that $T0 gets to maintain its optionality
because $T1 then could strip optionality later based on a
typing rule where `T <: T?`
Instead of always opening argument type represented by a collection
without type variables (to support subtyping when element is a labeled tuple),
let's try original type first and if that fails use a slower path with
indirection which attempts `array upcast`. Doing it this way helps to
propagate contextual information faster which fixes a performance regression.
Resolves: rdar://problem/54580247
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.
Number the parameters starting at 1 in order to
match other diagnostics such as
diag::missing_argument_positional, and change the
text to make it explicit that we're referring to
the parameter position (rather than argument
position).
Correct a regression related to use of partially applied initializers,
which should be rejected only if it happens in a delegation chain.
Resolves: [SR-10837](https://bugs.swift.org/browse/SR-10837)
Resolves: rdar://problem/51442825
Originally `filterContextualMemberList` would only return a limited
set of closeness kinds `CC_GeneralMismatch`, `CC_Argument{Label, Count}Mismatch`,
and unavailable/inaccessible. At some point later it also started
matching almost everything besides `CC_SelfMismatch` and logic in
`visitUnresolvedMemberExpr` needs to get adjusted to account for that.
Resolves: rdar://problem/50668864
Situations like:
```swift
struct S {}
func foo(_ s: S.Type) {
_ = s()
}
```
Used to be diagnosed in solution application phase, which means that
solver was allowed to formed an incorrect solution.
When the compiler fails to find an overload with suitable parameter or return types, it often attaches a note listing the available overloads so that users can find the one they meant to use. The overloads are currently ordered in a way that depends on the order they were declared, so swift-evolve would sometimes cause tests involving these diagnostics to fail.
This change emits the list in a textually-sorted order instead. The names were already being sorted as they were inserted into a std::set, so this shouldn’t significantly slow down the diagnostic.
While trying to find a fixed type for a given type variable, check if
it has representative and if it does, reflect that in the returned type.
Resolves: rdar://problem/34670592
An early optimization in constraint generation attempted to simplify
type construction (e.g., X(...)) when the type in question has no
failable initializers. However, the optimization didn't appropriately
clear out the cached bit when new information became available (e.g.,
new conformances, new extensions), and didn't seem to help anything
performance-wise (type-checking times didn't increase at all when I
turned this off).
Fixes rdar://problem/30588177.
For example, if someone tries to use the newly-generic type Cache,
from Foundation:
var cache = Cache()
they'll now get a fix-it to substitute the default generic parameters:
var cache = Cache<AnyObject, AnyObject>()
The rules for choosing this placeholder type are based on constraints
and won't be right 100% of the time, but they should be reasonable.
(In particular, constraints on associated types are ignored.)
In cases where there's no one concrete type that will work, an Xcode-
style placeholder is inserted instead.
- An unconstrained generic parameter defaults to 'Any'.
- A superclass-constrained parameter defaults to that class,
e.g. 'UIView'.
- A parameter constrained to a single @objc protocol (or to AnyObject)
defaults to that protocol, e.g. 'NSCoding'.
- Anything else gets a placeholder using the generic parameter's name
and protocol composition syntax.
rdar://problem/27087345
along with recent policy changes:
- For expression types that are not specifically handled, make sure to
produce a general "unused value" warning, catching a bunch of unused
values in the testsuite.
- For unused operator results, diagnose them as uses of the operator
instead of "calls".
- For calls, mutter the type of the result for greater specificity.
- For initializers, mutter the type of the initialized value.
- Look through OpenExistentialExpr's so we can handle protocol member
references propertly.
- Look through several other expressions so we handle @discardableResult
better.
information about where the archetype was defined. Before:
t.swift:6:17: error: generic parameter 'T' could not be inferred
var a : Int = A.foo()
^
After:
t.swift:6:17: error: generic parameter 'T' could not be inferred
var a : Int = A.foo()
^
t.swift:2:8: note: 'T' declared as parameter to type 'A'
struct A<T> {
^
a constraint system in "allowFreeTypeVariables" mode. Previously, we
only allowed a few specific constraints, now we allow any relational and
member constraints. The later one is a big deal because it means that we
can allow ".Foo" expressions as ambiguous solutions, which CSDiags can
handle well.
This unblocks solving 23942743 and enables some minor improvements across
the board, including diagnosing things like this better:
Optional(.none) // now: generic parameter 'T' could not be inferred
That said, it also just permutes some non-awesome diagnostics.
There's still work left to do. In terms of next steps, there's still rdar://problem/22126141, which covers removing the 'workaround' overloads for print (that prevent bogus overload resolution failures), as well as providing a decent diagnostic when users invoke print with 'appendNewline'.
Swift SVN r30976
"unavoidable failure" path, along with Failure::DoesNotHaveNonMutatingMember and
just doing some basic disambiguation in CSDiags.
This provides some benefits:
- Allows us to plug in much more specific diagnostics for the existing "only has
mutating members" diagnostic, including producing notes for why the base expr
isn't mutable (see e.g. test/Sema/immutability.swift diffs).
- Corrects issues where we'd drop full decl name info for selector references.
- Wordsmiths diagnostics to not complain about "values of type Foo.Type" instead
complaining about "type Foo"
- Where before we would diagnose all failures with "has no member named", we now
distinguish between when there is no member, and when you can't use it. When you
can't use it, you get a vauge "cannot use it" diagnostic, but...
- This provides an infrastructure for diagnosing other kinds of problems (e.g.
trying to use a private member or a static member from an instance).
- Improves a number of cases where failed type member constraints would produce uglier
diagnostics than a different constraint failure would.
- Resolves a number of rdars, e.g. (and probably others):
<rdar://problem/20294245> QoI: Error message mentions value rather than key for subscript
Swift SVN r30715
detailed analysis of callees, which give us overload sets in more cases,
producing notes more consistently, and producing much better diagnostics
for the curried cases in test/Constraints/diagnostics.swift.
This also allows us to eliminate getCalleeName, which simplifies things
in CSDiags.
Swift SVN r30491
rationalizing how it handles members and curried functions, also paving
the way for future improvements. This implements the infrastructure but
keeps the functionality the same (the only functionality change is that
it works a bit better with vardecls of function type).
Swift SVN r30464
disjunction candidate set for a constraint that fails to match, not just
a single Bind within it. This eliminates the arbitrary nature of picking
one match, allowing us to diagnose the entire candidate set.
This exposed that we were trying to do argument matching of 'self' against
the partially curried arguments. Adjust the hack we have for that a bit to
make things work, but there are bigger problems for argument matching that
will need to be addressed.
Swift SVN r30064
facilities used by operators etc. This required a bunch of changes to make
the diagnostics changes strictly an improvement:
- Teach the new path about calls to TypeExprs.
- Teach evaluateCloseness some simple things about varargs.
- Make the generic diagnosis logic produce a better error when there is
exactly one match.
Overall, the resultant diagnostics are a step forward: we now produce candidate
set notes more uniformly, and the messages about some existing ones are
more specific. This is just another stepping stone towards progress though.
Swift SVN r30057
When a line begins with '.', it's almost always due to a method chain, not an attempt to start an expression with a contextual member lookup. This is a more principled grammar rule than the long tail of hacks we've been putting up to try to accommodate "builder pattern" usages. Fixes rdar://problem/20238557.
Swift SVN r29606
This makes it clearer that expressions like "foo.myType.init()" are creating new objects, instead of invoking a weird-looking method. The last part of rdar://problem/21375845.
Swift SVN r29375
If 'x.init' appears as a member reference other than 'self.init' or 'super.init' within an initializer, treat it as a regular static member lookup for 'init' members. This allows a more explicit syntax for dynamic initializations; 'self.someMetatype()' looks too much like it's invoking a method. It also allows for partial applications of initializers using 'someMetatype.init' (though this needs some SILGen fixes, coming up next). While we're in the neighborhood, do some other correctness and QoI fixes:
- Only lookup initializers as members of metatypes, not instances, and add a fixit (instead of crashing) to insert '.dynamicType' if the initializer is found on an instance.
- Make it so that constructing a class-constrained archetype type correctly requires a 'required' or protocol initializer.
- Warn on unused initializer results. This seems to me like just the right thing to do, but is also a small guard against the fact that 'self.init' is now valid in a static method, but produces a newly-constructed value instead of delegating initialization (and evaluating to void).
Swift SVN r29344
Most tests were using %swift or similar substitutions, which did not
include the target triple and SDK. The driver was defaulting to the
host OS. Thus, we could not run the tests when the standard library was
not built for OS X.
Swift SVN r24504
