...and collapse StaticVar/ClassVar and StaticLet/ClassLet into
StaticProperty/ClassProperty.
"var" and "let" aren't great nouns to use in diagnostics to begin with,
especially alongside semantic terms like "instance method". Focus on
the type vs. non-type aspect instead with "property", which better
matches how people talk about member vars (and lets) anyway.
When a `fileprivate` method is declared in a `private`
extension, a warning is raised since access level
`fileprivate` is literally higher than `private`.
This is not appropriate because extensions are top level
declarations, for which `private` and `fileprivate` are
equivalent. This patch stops such warnings.
Resolves: SR-8306.
That is, if there's a problem with a witness, and the witness comes
from a different extension from the conformance (or the original type,
when the conformance is on an extension), put the main diagnostic on
the conformance, with a note on the witness. This involves some
shuffling and rephrasing of existing diagnostics too.
There's a few reasons for this change:
- More context. It may not be obvious why a declaration in file
A.swift needs to be marked 'public' if you can't see the conformance
in B.swift.
- Better locations for imported declarations. If you're checking a
conformance in a source file but the witness came from an imported
module, it's better to put the diagnostic on the part you have
control over. (This is especially true in Xcode, which can't display
diagnostics on imported declarations in the source editor.)
- Plays better with batch mode. Without this change, you can have
diagnostics being reported in file A.swift that are tied to a
conformance declared in file B.swift. Of course the contents of
A.swift also affect the diagnostic, but compiling A.swift on its
own wouldn't produce the diagnostic, and so putting it there is
problematic.
The change does in some cases make for a worse user experience,
though; if you just want to apply the changes and move on, the main
diagnostic isn't in the "right place". It's the note that has the info
and possible fix-it. It's also a slightly more complicated
implementation.
* [Diagnostics] Improve accessibility diagnostics for inheritance from generic classes
Fixed misleading warning when message pointed to the type's superclass access level instead of the access level of the type used as a generic parameter of the superclass when inheriting
* updated 'Compatibility' tests (warnings)
* updated the diagnostic's error version
Resolves: SR-7349
They're already not subclassable publicly, so it's okay for the
initializer to not be available to cross-module clients, just like if
it were non-'required'. This allows constructing a class instance
chosen at runtime /within/ the module without having to expose the
existence of the constructor to everybody.
rdar://problem/22845087
The previous code was too clever in trying to avoid work and missed
the fact that ClassDecl::getSuperclass produces an interface type but
the types in the inheritance clause are contextual types.
This actually successfully built:
- in non-WMO builds with a public subclass and an internal base class,
because the internal class symbol wouldn't get stripped out.
- in WMO builds with an internal subclass and a private base class,
because 'private' has no distinction at the linkage level for a WMO
build.
However, it's highly likely that trying to import a library containing
such types would result in instability (read: compiler and debugger
crashes), and it's clearly a mistake to allow this. (If you can't show
your superclass to a user in a library's generated interface,
something's definitely gone wrong.)
https://bugs.swift.org/browse/SR-6206
