There was undefined behavior here; we were calling
members.append(members.begin(), members.begin() + index),
which is invalid because 'members' is the new array of
members being built, which is empty at this point!
(...is constrained to be a subtype of another)
Previously the compiler would just mark the entry in the inheritance
clause invalid and move on without emitting any errors; in certain
circumstances in no-asserts builds this could actually lead to
everything working "correctly" if all conforming types happened to
pick the same concrete type for both associated types. In Swift 4 this
can actually be enforced with a same-type requirement, which will
guarantee that the two associated types are the same even in generic
contexts.
This fix avoids assertions and crashes, but the diagnostic is still
incorrect, and in the simple case of the inheritance clause it's
redundant. Doing something better and possibly even downgrading it to
a warning in Swift 3 mode is tracked by rdar://problem/32409449.
Initial patch by Slava, fixed up by me.
Once we're finalizing same-type-to-concrete and superclass
constraints, replace any unresolved DependentMemberTypes with their
resolved counterpairs. This allows us to simplify
DependentGenericTypeResolver, which only builds unresolved
DependentMemberTypes now, and eliminates the penultimate use of
ArchetypeResolutionKind::AlwaysPartial.
Instead of validating sub-expressions included in the closure's result
`diagnoseAmbiguousMultiStatementClosure` was only checking parent expression
by mistake.
Instead, introduce a new hasDependentMember() recursive property.
The only place that cares about this is associated type inference,
where I changed all existing hasTypeParameter() checks to instead
check (hasTypeParameter() || hasDependentMember()). We could
probably refine this over time and remove some of the
hasTypeParameter() checks, but I'm being conservative for now.
Fixes <https://bugs.swift.org/browse/SR-4575> and
<rdar://problem/31603113>.
If a lazy var has no declared type, we have to type check the
initializer to get a type before we can build the getter.
Then, the initializer is type checked as part of the getter
again.
Use the new SkipApplyingSolution flag when type checking for
the first time. We still end up doing redundant work, but by
not applying the solution we avoid feeding invalid AST nodes
back into the constraint solver.
This fixes some bad diagnostics and crashes.
Fixes <https://bugs.swift.org/browse/SR-2616> and
<rdar://problem/28313602>.
Record the initializer type as soon as we have a solution, before
it is applied, and get the type from the constriant system instead
of from the final type checked expression.
Note that the coerceToMaterializable() was unnecessary, since we
always coerce the value to an rvalue type with coerceToType().
Eventually coerceToMaterializable() should go away.
This is mostly NFC, except using the result of simplifyType() rather
than the type of the final expression changes some diagnostics where it
appears we were previously losing sugar.
Also this accidentally fixes a crasher. Unfortunately the underlying
issue is still there (applying a solution has bugs with opened
existentials "leaking" out) -- this merely masks the problem by
getting the initializer type directly from the constriant system.
This speeds up construction of a String from large Character representations,
and various other operations that would otherwise require additional grapheme
breaking just to interpret the Character.
Recursive concrete and superclass constraints are detected
per-equivalence-class; record them that way.
Use that information to drop recursive concrete and superclass
constraints from the resulting signature, which frees the canonical
generic signature builder from having to worry about such recursive
constraints. This eliminates the invalid-code crashes introduced in
the prior commit that disabled finalization for the canonical GSBs, as
well as fixing one other random crash-on-invalid.
* Give Sequence a top-level Element, constrain Iterator to match
* Remove many instances of Iterator.
* Fixed various hard-coded tests
* XFAIL a few tests that need further investigation
* Change assoc type for arrayLiteralConvertible
* Mop up remaining "better expressed as a where clause" warnings
* Fix UnicodeDecoders prototype test
* Fix UIntBuffer
* Fix hard-coded Element identifier in CSDiag
* Fix up more tests
* Account for flatMap changes
When errors occur in the processing of expressions, we can end up with
invalid ASTs where the application of an operator declared within a
type is missing its "self" argument. Tolerate such ASTs in the
error-handling checker.
Swift 3 supported limited argument destructuring when it comes to
declaring (trailing) closures. Such behavior has been changed by
SE-0110. This patch aims to provide better error message as well
as fix-it (if structure of the expected and actual arguments matches)
to make the migration easier and disambiguate some of the common
mistakes.
Resolves: SR-4738, SR-4745, rdar://problem/31892961.
When performing a name lookup from inside of a protocol
or extension, skip directly to the source file context
when we are done visiting the protocol or extension.
Otherwise, if we have invalid code where the protocol
or extension is nested inside another type, we might
find a member whose type contains generic parameters
of the outer type; these parameters will not resolve,
since we do not model protocols or extensions nested
inside generic contexts (yet?).
This supercedes an earlier workaround for a similar
issue; the new workaround fixes more crashes.
This is needed to avoid crasher regressions with an
upcoming patch.
When we have a potential assignment of associated types to type
witnesses during associated type inference, check that set of type
witnesses against the requirements in the requirement signature, so
that we can reject any solutions that fail some of the protocol's
requirements.
This is most of rdar://problem/31830524 --- but gets thwarted by the
inability of associated type inference to work across multiple
protocols.
* [stdlib] String : RangeReplaceableCollection & BidirectionalCollection
* Add source compatibility hack for Swift.max
* Add source compatibility hack for Swift.min
* Remove redundant conformance in benchmarks
* Fix stupid typo I thought I'd already pushed
* XFAIL testing now-redundant conformance
* XFAIL an IDE test for now
Consider the following setup:
struct GenericStruct<T> {
typealias Dependent = T
typealias Concrete = Int
}
We have no way to model 'GenericStruct.Dependent' in the AST, so the
reference would crash. Instead, produce a diagnostic suggesting to
insert generic parameters, like 'GenericStruct<Int>.Dependent'.
The reference 'GenericStruct.Concrete' is fine though, and should
not crash; add a test that it works.
Fixes <https://bugs.swift.org/browse/SR-4390>, <rdar://problem/31480755>.
Fix an odd corner case when UseErrorTypes was off; we would
return the empty type if dependent member type substitution
failed, but otherwise return the original type if it was a
generic type parameter or an archetype.
Now, if UseErrorTypes is off, return the empty type in both
cases, even if the original type is 'primary'.
We were putting conformance requirements on the representative of the
equivalence class, rather than directly on the potential archetype on
which the conformance requirement was specified. This violates the
invariant used when forming protocol-requirement sources that we never
reseat a requirement onto the representative (which would
have become a problem when implementing recursive protocol
constreaints) as well as masking a GSB idempotency issue that comes
from same-type requirements where the right-hand side was not
guaranteed to refer to the archetype anchor *within* that subcomponent.
