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
This commit changes fixit messages from a question/suggestion to an
imperative message for protocol conformances and switch-case. Addresses
https://github.com/apple/swift/issues/67510.
* [TypeChecker] Enclosing stubs protocol note within editor mode
* [test] Removing note from test where there is no -diagnostics-editor-mode flag
* Formatting modified code
* [tests] Fixing tests under validation-tests
In preparation for checkEnumRawValues being turned into a request, move the common diagnostics to the decl checker so they're always emitted at the right time.
Under non-editor mode, the fixit for inserting protocol stubs is associated with a note
pointing to the missing protocol member declaration which could stay in a separate file from
the conforming type, leading to the behavior of rdar://51534405. This change checks if
the fixit is in a separate file and issues another note to carry the fixit if so.
rdar://51534405
...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.
In Swift 3 mode, the canonical private DeclContext should
not look through extensions.
The only way I can reproduce this is with a missing warning
and we don't really care about missing warnings in Swift 3 mode.
However, the next patch in this PR regresses more things so
let's fix it properly.
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.
Rather than relying on the NameAliasType we get by default for references
to non-generic typealiases, use BoundNameAliasType consistently to handle
references to typealiases that are formed by the type checker.
This eliminates the need for an ugly and incomplete hack to suppress
noescape inference for setter arguments. It also means we stop emitting
redundant diagnostics for problems in storage types.
This was done back in Swift 3.0.1 or 3.0.2. Let's finally make them
errors in Swift 4!
I also fixed up a number of '%error' entries in diagnostics that can
actually happen in invalid code. These are the ones that were already
present in the warnings.
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.
