You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
Copy file name to clipboardExpand all lines: test/Sema/accessibility_private.swift
+21Lines changed: 21 additions & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -210,3 +210,24 @@ fileprivate struct SR2579 {
210
210
privatevarouterProperty=Inner().innerProperty // expected-warning {{property should not be declared in this context because its type 'SR2579.Inner.InnerPrivateType' uses a private type}}
211
211
varouterProperty2=Inner().innerProperty // expected-warning {{property should be declared private because its type 'SR2579.Inner.InnerPrivateType' uses a private type}}
212
212
}
213
+
214
+
// FIXME: Dependent member lookup of typealiases is not subject
215
+
// to accessibility checking.
216
+
structGeneric<T>{
217
+
fileprivatetypealiasDependent=T
218
+
}
219
+
220
+
varx:Generic<Int>.Dependent=3
221
+
// expected-error@-1 {{variable must be declared private or fileprivate because its type uses a fileprivate type}}
0 commit comments