Basically if the underlying type of a typealias was dependent on
generic parameters from context, it wouldn't participate in
accessibility checking.
Turns out people were (accidentally) relying on this behavior, so
add a simulation of it in Swift 3 mode by ignoring such typealiases
entirely.
Fixes <rdar://problem/29549232>.
This eliminates a usage of SubstitutedType.
Unfortunately, we still need a simpler version of the old
check for the case where a 'var' has no explicit type written,
and instead the type is inferred from the initializer
expression.
The check for inferred types of vars no longer looks at
SubstitutedType, so it misses the accessibility of dependent
typealias members. A new test case demonstrates the problem.
Note that dependent typealiases were substituted away as far as
the user is concerned anyway, not showing up in generated
interfaces or diagnostics.
Also the new logic is more accurate in the case where a
TypeRepr is present, which is most of the time.
First, ensure all ParamDecls that are synthesized from scratch are given
both a contextual type and an interface type.
For ParamDecls written in source, add a new recordParamType() method to
GenericTypeResolver. This calls setType() or setInterfaceType() as
appropriate.
Interestingly enough a handful of diagnostics in the test suite have
improved. I'm not sure why, but I'll take it.
The ParamDecl::createUnboundSelf() method is now only used in the parser,
and no longer sets the type of the self parameter to the unbound generic
type. This was wrong anyway, since the type was always being overwritten.
This allows us to remove DeclContext::getSelfTypeOfContext().
Also, ensure that FuncDecl::getBodyResultTypeLoc() always has an interface
type for synthesized declarations, eliminating a mapTypeOutOfContext()
call when computing the function interface type in configureInterfaceType().
Finally, clean up the logic for resolving the DynamicSelfType. We now
get the interface or contextual type of 'Self' via the resolver, instead
of always getting the contextual type and patching it up inside
configureInterfaceType().
Use the flag added in the previous commit to look for inaccessible
values when an (unqualified) DeclRefExpr can't be resolved.
Finishes rdar://problem/27663403.
...and use it when top-level type lookup fails, to produce better
diagnostics.
Really this should be using an option set, or setting flags on the
UnqualifiedLookup instance or something, but I want to cherry-pick
this to the swift-3.0-branch without major disturbances.
More rdar://problem/27663403
...to be compatible with Swift 3. Fortunately these cases are all safe;
they're the cases that would all be 'fileprivate' in Swift 2.
Finishes https://bugs.swift.org/browse/SR-2579, although we'll need a
follow-up bug to turn this /back/ into an error in Swift 4.
This was a correct compile-time optimization for Swift 2, but Swift 3
has multiple levels of "private" that need to be taken into account.
This is a purely /subtractive/ change, so the next commit will
downgrade this to a warning in cases where it would have been accepted
in 3.0GM.
https://bugs.swift.org/browse/SR-2579
* Private members may not satisfy protocol requirements, ever.
...because by construction they can be invoked from outside of the
type.
Finishing up SE-0025 ('private' and 'fileprivate').
* Update docs and mark SE-0025 ('private' and 'fileprivate') as done!
There's still improvements we can make (see 508e825f), but the feature
is in place and should be working correctly.
