for initializer lookup, allowing it to produce more specific diagnostics
when referring to a private initializer that the compiler can see.
In addition to improving diagnostics, this allows us to eliminate the
NoPublicInitializers failure kind.
When member lookup completely fails and when CSDiags is the one performing
the lookup, reissue another lookup that ignores access control. This allows
it to find inaccessible members and diagnose them as such, instead of pretending
we have no idea what the user wants. We now produce an error message like this:
main.swift:1:6: error: 'foo' is inaccessible due to 'private' protection level
C().foo()
^
test.swift:1:35: note: 'foo' declared here
internal class C { private func foo() {} }
^
instead of:
main.swift:1:2: error: value of type 'C' has no member 'foo'
C().foo()
^~~ ~~~
While we could allow declarations with the same name and type if all but one
are private, it feels a bit subtle that one declaration at top-level scope can
shadow another declaration at top-level scope elsewhere in the module. Let's
start with this for now.
Currently guarded by -enable-private-discriminators.
Part of rdar://problem/17632175
Swift SVN r21602
Rather than just saying "'Foo' is not constructible with '()'", say
"'Foo' cannot be constructed because it has no accessible initializers",
which would help framework authors realize what they did wrong.
<rdar://problem/17717714>
Swift SVN r20232
This applies to both qualified and unqualified lookups, and is controlled
by the -enable-access-control and -disable-access-control flags. I've
included both so that -disable-access-control can be put into specific tests
that will eventually need to bypass access control (e.g. stdlib unit tests).
The default is still -disable-access-control.
Swift SVN r19146
