Shrinking such expressions will immediately restrict the solution set
to the default literal types (Int or Double), causing later solutions
to fail. Fixes rdar://problem/30220565.
Swift 3.0 allowed constructing an enum or calling a function-typed
property with multiple arguments even when a single argument of tuple
type was expected. Emulate that in Swift 3 mode by wrapping in an
extra level of parentheses when the situation comes up.
Last vestiges of fallout from SE-0110. Hopefully last, anyway. A nice
follow-up to this commit might be to /warn/ in Swift 3 mode when this
happens.
rdar://problem/30171399
When I refactored the handling of bridging conversions (e.g.,
valueType as? NSClassType), I broke the path that performed a bridging
conversion followed by a conversion to an existential, e.g.,
"some-bridged-value-type as CVarArg". Reinstate such use cases.
Fixes rdar://problem/30195862.
Without this, CSGen/CSSimplify and CSApply may have differing
opinions about whether e.g. a let property is settable, which
can lead to invalid ASTs.
Arguably, a better fix would be to remove the dependency on the
exact nested DC. For example, we could treat lets as settable
in all contexts and then just complain later about invalid
attempts to set them. Or we could change CSApply to directly
use the information it already has about how an l-value is used,
rather than trying to figure out whether it *might* be getting set.
But somehow, tracking a new piece of information through the
entire constraint system seems to be the more minimal change.
Fixes rdar://29810997.
Revert 7c665c105b because it results in a
much worse source compatibility regression than the one it was intended
to fix.
The problem is that it results in force-unwrapping IUOs, which can lead
to cases where we prefer type-checking solutions that choose methods
over properties where we used to choose properties. So for example a
collection literal like [x] will result in a collection with a method
named 'x' in it rather than a property named 'x'.
I'll be looking at other solutions which fix both the original
compatibility regression as well as retain the behavior in the new test
added here.
Fixes SR-3715 and rdar://problem/30176166.
This is a generic signature that stores exactly the requirements that a
protocol decl introduces, not letting them be implied by the Self :
Protocol requirement, nor storing any requirements introduced by the
protocols requirements.
Specifically, suppose we have
protocol Foo {}
protocol Bar {}
protocol Baz {
associatedtype X : Foo
}
protocol Qux: Baz {
associatedtype X : Bar
}
The normal generic signature and (canonical) protocol requirement
signature of `Baz` will be, respectively
<Self where Self : Baz>
<Self where Self : Baz, Self.X : Foo>
And for `Qux`, they will be:
<Self where Self : Qux>
<Self where Self : Qux, Self : Baz, Self.X : Bar>
Note that the `Self.X : Foo` requirement is not listed.
For the moment, this is unused except for `-debug-generic-signatures`.
It turns out we've been loading decls from the ClangImporter when
parsing SIL forever; when we do that without a TypeChecker around, the
imported decls aren't always set up correctly (because the TypeChecker
is supposed to do part of that work). For now, just don't verify
imported declarations in loaded modules when parsing SIL.
When considering an implementation from a protocol extension as a possible witness to a protocol requirement, and using that witness to try to infer the protocol's associated types, we would sometimes consider `AssocType == ConformingType.AssocType` as a potential solution, even though this is a tautology; we would subsequently mark the potential solution as failed (because ConformingType.AssocType doesn't exist yet; it doesn't conform to any protocols) even when the witness is necessary to infer other associated types. Worse, this would introduce an order dependency when certain potential witnesses were visited before the right associated types were inferred. Fix this by filtering out useless tautological inferred witnesses before trying to validate them for conforming to the necessary requirements. Fixes rdar://problem/29954938.
When two associated types with the same name are on the same dependent
type T, introduce a same-type constraint between the the corresponding
potential archetypes. This eliminates ordering dependencies in the
archetype builder.
Fixes the reduced test case from rdar://problem/23149063, but doesn't
fully address the idea that we should be tracking associated type
redeclarations in a meaningful way.
In Swift 3, these attributes were changed to apply to the type,
and not the parameter. If they appear on the parameter, we would
go down a diagnostic code path.
When checking a generic function signature, we might not have a
contextual type for the parameter yet, so bail out instead of
crashing.
This still doesn't work in a number of cases, but fixes a case
that used to work in Swift 3.0 which was affecting the Dollar.swift
library.
Fixes <rdar://problem/29007725>.
In ConstraintGenerator::visitDictionaryExpr(), if the dictionary_expr has a
contextual type which is also a dictionary type, use it to add a new type
constraint for each of the dictionary_expr's elements. This has a huge effect
on solver performance for dictionary literals with elements that have
overloading. The approach closely follows that used in
ConstraintGenerator::visitArrayExpr(), which has included a similar
optimization (from git commit a22b391) for over two and a half years.
I've also added a couple of new test cases which would trigger the bug without
this fix.
If a non-generic type is specialized a fixit is provided to remove the
generic arguments. The DiagnosticEngine turns a SourceRange into a
CharSourceRange by re-lexing the token at `SourceRange::End`.
The problem solved by this change occurs, if the non-generic type is
nested in an other generic type like this:
let a: GenericType<NongenericType<NongenericType>>
The lexer doesn't know that the closing angle brackets are individual
tokens leading to the removal of both of them. We can work around this
by directly specifying the start and end locations.
Value type initializers must initialize stored properties directly
if they do not delegate to another initializer via self.init().
Since direct stored property access is not permitted for resilient
value types from outside their resilience domain, this means that
such initializers are prohibited in two cases:
- If the initializer is defined in an extension from outside the
value type's resilience domain
- If the initializer is public and @_inlineable, since it might get
inlined outside the value type's resilience domain
Right now, such initializers cannot *assign* to self either;
I filed <https://bugs.swift.org/browse/SR-3686> to track the issue.
Protocol members can be directly referenced from protocol extensions
and generic functions. Since protocol members do not have accessibility
distinct from the protocol itself, ignore them, since they won't carry
the @_versioned attribute.
While workign on this I uncovered an interesting bug where we allow
members of protocol extensions to be more accessible than the protocol
itself, but then we give the symbols hidden visibility at the SIL level
anyway.
I filed <https://bugs.swift.org/browse/SR-3684> to track this issue.
ConstraintSystem::simplifyType() replaced types with their fixed types
from the global map.
Solution::simplifyType() replaced types with their fixed types from the
current bindings.
There were some minor differences between the two, and some dead code.
These are never part of an @objc protocol, so we shouldn't bother
looking for them and certainly shouldn't expect them to be there.
Fixes a crash introduced in 1f2121377.
rdar://problem/30101703
Now that NameAliasTypes desugar to interface types, it is possible
to have a protocol requirement type contain a NameAliasType which
contains an associated type:
protocol P {
associatedtype Element
typealias Elements = [Element]
func process(elements: Elements)
}
In Swift 3, the typealias would be desugared at name lookup time
in this case, but this is no longer the case, as a result associated
type inference stopped working in this example.
Fixes <https://bugs.swift.org/browse/SR-3641>.
