Previously we would check TMF_UnwrappingOptional flag, which does not
stick with the constraint, so it would not always persist. Now, add a
new OptionalPayload locator element, which is more correct.
Fixes <rdar://problem/30429709>.
Name lookup can cause import of some Clang declaration, which in turn
need a type checker. Make sure a type checker exists at this time.
This is a baby step toward having the type checker always available,
which is really the end goal. For now, we need this for better generic
environment (de-)serialization.
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>.
When comparing the parameters of two declarations for the purpose of
partial ordering, it doesn't make sense to compare the parameter
labels: they're dealt with separately and aren't conceptually part of
the type.
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.
New generic environments should be created directly from the generic
signature, without having to explicitly create an archetype
builder. Now, only the canonical archetype builders are ever used to
create a generic environment.
Clean up the representation of PotentialArchetype in a few small ways:
* Eliminate the GenericTypeParamType* at the root, and instead just
store a GenericParamKey. That makes the potential archetypes
independent of a particular set of generic parameters.
* Give potential archetypes a link back to their owning
ArchetypeBuilder, so we can get contextual information (etc.) when
needed. We can remove the "builder" arguments as a separate step.
Also, collapse getName()/getDebugName()/getFullName() into
getNestedName() and getDebugName(). Generic parameters don't have
"names" per se, so they should only show up in debug dumps.
In support of the former, clean up some of the diagnostics emitted by
the archetype builder that were using 'Identifier' or 'StringRef'
where they should have been using a 'Type' (i.e., the type behind the
dependent archetype).
SubstitutionList is going to be a more compact representation of
a SubstitutionMap, suitable for inline allocation inside another
object.
For now, it's just a typedef for ArrayRef<Substitution>.
A new SubstitutionMap::getProtocolSubstitutions() method handles
the case where we construct a trivial SubstitutionMap to replace
the protocol Self type with a concrete type.
When substituting one opened existential archetype for another,
use the form of Type::subst() that takes two callbacks instead of
building a SubstitutionMap. SubstitutionMaps are intended to be
used with keys that either come from a GenericSignature or a
GenericEnvironment, so using them to replace opened archetypes
doesn't fit the conceptual model we're going for.
The problem is that the derived property's materializeForSet was
being synthesized after recordOverride() was called, so the new
accessor never got setOverridenDecl() called on it.
As a result, SIL didn't know that the derived materializeForSet
should replace the vtable entry for the base class materializeForSet.
The more fundamental problem here is that even after some recent
cleanups, accessors are still sometimes type checked before
the AbstractStorageDecla and sometimes after. So things like
inferring final, dynamic and overrides have to be duplicated in
multiple places.
Fixes <https://bugs.swift.org/browse/SR-3840> and
<rdar://problem/30336146>.
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
The prohibition in Swift 3.0 missed the case where the single-element tuple was wrapped in extra parens as the only argument of a function. We've ripped out parts of the type checker that try to cope with single-element tuples, and it would be risky and bug-prone to try to admit this code, so it's better to fix the ban than to try to accept the code, alas. Fixes SR-3788.
