* [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.
This crash happens because shouldAddSelfFixit (a check for the expected_self_before_reference diagnotic) performs name lookup inside the parser, which causes a search for extensions, which triggers the mangler, which can get confused if we are in an unfinished declaration (a PatternBindingInitilizer in this case).
A cleaner fix would be to move that logic inside Sema, but it would require much more refactoring that I don’t feel comfortable doing. Instead, this band-aid checks if the innermost type is inside a local context. If that’s the case, we can ignore the search for extensions.
The @_versioned accessibility check is done against the formal access. But the diagnostics is printed with getAccessForDiagnostics. In cases where the effective access is internal, the diagnostics will crash. Example:
```
class A { // implicitly internal
@_versioned public var a: Int = 0 // explicity public
}
```
New GenericTypeParamDecls should always be created with an
InvalidDepth, to prevent canonicalization before the generic
parameter list has been type checked.
If typechecking fails, the expression will have unsolved type variables
written into it. This Crashes The Compiler.
In that case, there’s no reason to keep a tree of dangling references
around. Detach the initializer expression from the AST, but continue
to typecheck it to see if we can get some useful diagnostics out of it.
The list of directly inherited protocols of a ProtocolDecl is already
encoded in the requirement signature, as conformance constraints where
the subject is Self. Gather the list from there rather than separately
computing/storing the list of "inherited protocols".
After we call into typeCheckExpression() we need to cache the
resulting types in the constraint system type map because we later
call into code that reads the types out of the type map.
Fixes rdar://problem/30376186 as well as a couple crashers.
We allow a member of a type to be more accessible than the type
itself. In this case, the broader accessibility is ignored, and
the effective access of the member is constrained by the
accessibility of its parent type.
We sometimes construct DependentMemberTypes with an UnresolvedType
base. These are not "real" interface types and can end up in
places where we don't expect interface types, triggering an
assertion. Make sure such types don't respond true to hasTypeParameter().
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
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.
