We don't actually need the TypeLoc for anything, but it was still
getting type-checked, which means it doesn't get the benefit of
inference from the initial value. In some cases the actual type of the
ParamDecl seems to get reset to the TypeLoc's type as well. Just do
the simple thing and set it directly ahead of time.
Fixes a source compatibility issue with Swift 3.0.
https://bugs.swift.org/browse/SR-3893
If the nested type itself has generic constraints, we would
hit an assertion in requirement inference. Refactor some code
so that we can make the assertion more accurate.
Fixes <rdar://problem/30353095>.
This reverts part of #4038 which made the compiler consider it to be an `Explicit` conformance, breaking source code that was accepted in Swift 3.0 which declared a raw type as well as explicit conformance to `RawRepresentable` (reported as rdar://problem/30386658). While I'm here, a couple of spot fixes:
- Ensure an enum's raw value exprs are type-checked before checking conformances of any of its extensions, since the RawRepresentable conformance derivation will blow up if the raw value exprs haven't been checked. Fixes an order dependency issue if `extension Foo: RawRepresentable {}` gets checked before `enum Foo: Int { ... }`.
- Don't display the custom `enum_declares_rawrep_with_raw_type` diagnostic if the source location for the enum's inheritance clause is invalid, so that we don't emit a dislocated diagnostic.
Within an extension, references to other members of the extended type
are permitted without qualification. This is intended to work even
when the extended type was a nested type, although members of the
enclosing type are /not/ visible in this case. In order to implement
this, the type checker pre-checks to see if there are /any/ members
with this name and then rewrites the unqualified reference to a
qualified one, based on an unresolved TypeExpr with the name of the
enclosing type. Unfortunately, if the enclosing type is a nested type,
that isn't going to work very well---we find the correct declaration,
but fail to map it into context by virtue of not realizing where it
came from. Fix this by explicitly checking for this case.
https://bugs.swift.org/browse/SR-3847
ArchetypeBuilder::finalize() is needed to tie up any loose ends before
requesting a generic signature or generic environment. Make sure it
gets called consistently.
The canonicalization of dependent member types had some
nondeterminism. The root of the problem was that we couldn't
round-trip dependent member types through the archetype
builder---resolving them to a potential archetype lost the specific
associated type that was recorded in the dependent member type, which
affected canonicalization. Maintain that information, make sure that
we always get the right archetype anchor, and tighten up the
canonicalization logic within a generic signature.
Fixes rdar://problem/30274260 and should unblock some other work
that depends on sanity from the archetype builder and generic
signature canonicalization.
`1 { }` was parsed as a call expression with a trailing closure. This made the diagnostics for `var x = 1 { get { ... } }` extremely bad. Resolves SR-3671.
Introduce an algorithm to canonicalize and minimize same-type
constraints. The algorithm itself computes the equivalence classes
that would exist if all explicitly-provided same-type constraints are
ignored, and then forms a minimal, canonical set of explicit same-type
constraints to reform the actual equivalence class known to the type
checker. This should eliminate a number of problems we've seen with
inconsistently-chosen same-type constraints affecting
canonicalization.
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.
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>.
When enumerating requirements, always use the archetype anchors to
express requirements. Unlike "representatives", which are simply there
to maintain the union-find data structure used to track equivalence
classes of potential archetypes, archetype anchors are the
ABI-stable canonical types within a fully-formed generic signature.
The test case churn comes from two places. First, while
representatives are *often* the same as the archetype anchors, they
aren't *always* the same. Where they differ, we'll see a change in
both the printed generic signature and, therefore, it's
mangling.
Additionally, requirement inference now takes much greater
care to make sure that the first types in the requirement follow
archetype anchor ordering, so actual conformance requirements occur in
the requirement list at the archetype anchor---not at the first type
that is equivalent to the anchor---which permits the simplification in
IRGen's emission of polymorphic arguments.
Most property accessors have selectors matching their protocols, but
not all. Don't force the user to write '@objc' explicitly on an
accessor, which isn't even possible for stored properties.
More groundwork for rdar://problem/28543037.
Neither of the following is supported:
func g<T>(_: T) {
_ = {
struct S {}
}
}
struct G<T> {
let fn = {
struct S {}
}
}
Even though nested generic types are supported, the second example
is more like a type inside a function than a type inside a type,
because 'S' has no parent type.
Technically this is source-breaking but since neither SILGen nor
IRGen knew how to generate code for these I doubt anything worked.
Not really specific to typealiases; but we don't allow nominal types
to be nested inside protocols yet, and all other types of protocol
members have witnesses in the concrete type.
Fixes <https://bugs.swift.org/browse/SR-2792>.
There's no need to walk up from a function or type context -- if
no generic signature (or environment) is set, the parent won't have
one, either, and if we're in the middle of validating the child
context, using the parent's signature or environment to resolve
dependent types is just wrong.
If one of the associated types is witnessed by a generic parameter
from the function's scope, make sure it maps down to an ErrorType
instead of leaving it as a type parameter, which triggers an
assertion.
Eventually we'll plumb it through properly.
We would falsely diagnose the occurrence of the protocol
_in the inheritance clause_ as a "bad" usage of an
existential type, because the UnsupportedProtocolVisitor
was too eager in walking into nested Decls and Stmts.
Note that in one case we don't emit a diagnostic where we
did before, but this doesn't matter; the VarDecl in
question becomes invalid later, and only the order in
which the decls are visited changes.
Here, the 'self' value has a dynamic Self type, which we must strip
off when performing the conformance lookup.
Fixes <https://bugs.swift.org/browse/SR-2696>.
This patch contains several intertwined changes:
- Remove some unnecessary complexity and duplication.
- Adds a new TypeChecker::lookupUnqualifiedType() which bypasses most of
the logic in TypeChecker::lookupUnqualified(), such as the
LookupResultBuilder. Use this when resolving unqualified references
to types.
- Fixes for generic typealiases to better preserve the type parameters of
the parent type, and clean up the logic for applying the inner generic
arguments. Some uses of generic typealiases that used to crash now work,
and those tests have been uncommented.
- Avoid an unnecessary desugaring of TypeAliasDecls which map directly
to GenericTypeParamTypes. Once again this perturbs the source-stability
test.
- When looking up a nested type of a base class with a derived class base,
always use the base class as the parent of the nested type. This fixes
a recent regression where in some cases we were using the wrong parent.
Fixes <rdar://problem/29782186>.
When running diagnostics for single expression closures,
explicitly disallow to produce solutions with unresolved type variables,
because there is no auxiliary logic which would handle that and it's
better to allow failure diagnosis to run directly on the closure body.
Metatypes do not have member types and trying to look one up on a
generic parameter would cause a crash.
InOutTypes are not materializable and we should never be performing
name lookup into them.
