These are tests that fail in the next commit without this flag. This
does not add -verify-ignore-unrelated to all tests with -verify, only
the ones that would fail without it. This is NFC since this flag is
currently a no-op.
Some editors use diagnostics from SourceKit to replace build issues. This causes issues if the diagnostics from SourceKit are formatted differently than the build issues. Make sure they are rendered the same way, removing most uses of `DiagnosticsEditorMode`.
To do so, always emit the `add stubs for conformance` note (which previously was only emitted in editor mode) and remove all `; add <something>` suffixes from notes that state which requirements are missing.
rdar://129283608
Code like that is usually indicative of programmer error, and does not
round-trip through module interface files since there is no source
syntax to refer to an outer generic parameter.
For source compatibility this is a warning, but becomes an error with
-swift-version 6.
Fixes rdar://problem/108385980 and https://github.com/apple/swift/issues/62767.
warning.
These diagnostics are stricter in the RequirementMachine than in the GSB,
and there's code that relies on the more relaxed diagnostics in the source
compatibility suite. Downgrade these diagnostics to a warning using
warnUntilSwiftVersion(6).
If the access level of a protocol witness does not satisfies a requirement,
the compiler suggests marking it as the required level. This is not suitable
when the witness is in an extension whose specified access level is less than
the required level, since the fixit fights with other warnings in this case.
This patch identifies such case and produces improved diagnostics.
Resolves: SR-9793
This is reasonable to diagnose with a warning, but dropping the 'open'
down to 'public' isn't the right fix, because now it's not a valid
override. The declaration has to get moved to another extension instead,
or the extension has to not set a default access level.
This turned out to be a source compat issue because the same logic
that emits the fix-it also updates the access of the member, which
then resulted in "must be as accessible as the declaration it
overrides" in the /same/ build. It's not immediately clear what caused
this; probably something's just being validated in a different order
than it was before. The change makes sense either way.
Stepping back, it's weird that a warning would change how the compiler
saw the code, and while we could check for 'override' explicitly, we
can't know if the member might be satisfying a protocol requirement.
Better to just not guess at the right answer here.
rdar://problem/47557376&28493971
Previously if a declaration had both a Type and a TypeRepr available,
we would only check the access of the TypeRepr. However, this is
incomplete when the type is partially inferred, as in
public var inferredGenericParameters: Optional = PrivateStruct()
The new algorithm is to the Type first, then:
- if the Type is okay, move on to check the TypeRepr
- if the Type is not okay and we're in pre-Swift-5 mode, check the
TypeRepr, and if /that's/ okay downgrade the whole thing to a
warning.
Unfortunately, we can't /just/ check the Type in the "good" case,
because we don't always properly preserve sugar when going from a
TypeRepr that represents a typealias to the corresponding Type, and we
want to be able to fix those cases in the future. So we have to check
both.
This patch adds warning for redundant access-level modifiers
used in an extension. It also refines the diagnostics of
access_control_ext_member_more issues, in case the fixit
could suggest redundant modifiers.
Resolves: SR-8453.
...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
