Looking up the conformance @dynamic_self C<T> : P simply returns
the normal conformance C<T> : P.
If we later apply a substitution map to the conformance to
specialize T, we would call isSpecialized() on the substituted
type, which would return false. We would then hit an assertion
because the type type @dynamic_self C<Int> is not equal to the
(erroneously unsubstituted) conformance type C<T>.
Tweak the logic slightly to avoid this.
In an extension of a nested type, the extended type must be
fully qualified.
Also clean up the diagnostic logic a little bit and centralize
it in diagnoseUnknownType().
Fixes <https://bugs.swift.org/browse/SR-4379>.
Some messages said 'typealias' and others said 'type alias'.
Change everything to use 'type alias' consistently (except
when it's talking about the keyword itself).
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>.
Previously we prohibited unbound generics in the underlying
type of a typealias, but due to an oversight the check was
not performed when resolving a nested type.
So this worked:
struct Outer { struct Inner<T> {} }
typealias OuterInner = Outer.Inner
let _: OuterInner<Int> = Outer.Inner<Int>()
However it was easy to cause a crash this way by stating an
unbound generic type where one was not expected. Also,
unqualified types in a typealias did not get this treatment,
so the following did not work:
typealias MyOptional = Optional
Formalize the old behavior by allowing unbound generic types
in the underlying type of a typealias, while otherwise
prohibiting unbound references to nested types.
These tests included sources that are
based on Swift 3. They can be considered to be updated later to Swift 4, but it did not seem critical for what they were testing.
Normally name lookup from a where clause walks up to the parent
DeclContext, so it does not need to handle outer generic parameters
specially. But with an extension of a nested type, the outer
DeclContext is the source file, and the extension itself has a
chain of GenericParamLists linked by the OuterParameters field.
Added "-help" option to Options.td
Added also:
* Added "OPT_HELP" case in the main TestOptions.cpp switch. It uses the llvm options help functionality to provide up-to-date help
* Additional "Use -help for assistance" at the end of the error message that appears when calling an unknown option
Added their following tests, respectively::
* usage.swift, and
* wrong_arguments.swift
Extra: FIXME: in TestOptions::printHelp, suggesting a possible expansion for the printHelp option (details in file)
When the type checker forms a GenericSignatureBuilder to process
requirements, the GSB may look up concrete conformances. Route such
requests through TypeChecker::conformsToProtocol() so they can be
marked as used. This fixes multi-file scenarios where conformances
from another file might be used only in a generic signature in the
primary file, e.g., rdar://problem/31759258.
When the type checker forms a GenericSignatureBuilder to process
requirements, the GSB may look up concrete conformances. Route such
requests through TypeChecker::conformsToProtocol() so they can be
marked as used. This fixes multi-file scenarios where conformances
from another file might be used only in a generic signature in the
primary file, e.g., rdar://problem/31759258.
Specializations are implementation details, and thus shouldn't be
public, even if they are specializing a public function. Without this
downgrade, the ABI of a module depends on random internal code
(could change inlining decisions etc.), as well as swiftc's optimiser.
