Inherited designated initializers got the same availability
as the corresponding initialier in the superclass.
However if the superclass was more available than the subclass,
we would generate a diagnostic that a member cannot be more
available than its containing type.
This diagnostic had an unknown source location, since the
location was for a synthesized declaration, causing confusion.
Fixes <https://bugs.swift.org/browse/SR-7881> aka
<rdar://problem/40853731>.
When performing name lookup for UnresolvedDeclRefExpr, if a
local declaration after use is detected, we check outer results
to see if we can find better matching candidates before raising
a use_local_before_declaration error.
Resolves: SR-7660.
We have no generic environment in this case, and just need to print
the canonical generic parameter types.
Fixes <https://bugs.swift.org/browse/SR-7673>.
If a property had an inferred type that is a generic type alias,
we weren't checking the access level of the generic arguments.
This used to work in 4.1 because we didn't have a sugared
representation for generic type aliases, so we were checking
the substituted underlying type here. But now that NameAliasType
can store generic arguments, make sure we visit them here.
Fixes <rdar://problem/40188409>.
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.
'private' properties can't be accessed in extensions in Swift 3, so synthesizing
a conformance that reads from such things is going to be incorrect in an
extension.
Ensure that we grab the decl from the subscript expression so that we
can check whether it returns an IUO.
Also add tests for subscripts and failable inits.
These warnings are turning out to be pretty noisy for code that
declares IUOs (e.g. for @IBOutlets) and then passes them to
Objective-C APIs with parameters declared as _Nonnull id.
Since we bridge non-nil values successfully in most cases, and
previuosly written and correctly executing code is either not seeing
nil values passed in or are handling the nil (which is bridged as
NSNull), it seems like a nuisance to warn about these for existing
Swift versions.
We'll conditionalize the warning, and then users can deal with these
when moving to the new language version.
Fixes: rdar://problem/39886178
This works for all protocols except for Decodable on non-final classes, because
the init requirement has to be 'required' and thus in the type's declaration.
Fixes most of https://bugs.swift.org/browse/SR-6803.
Eagerly remove empty (sub-)spaces from constructors and disjuncts
to minimize number of operations required to check space coverage.
Also return original constructor space while subtracting a pair of
constructors, instead of disjunct, if subtraction of one of its
sub-spaces produced the same space, this reduces the number of
disjuncts in the path.
Resolves: rdar://problem/39710335
* [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
* [Diagnostics] SR-7445 Improve diagnostics for assignment failures
* modified messages for assignments to function calls,
modified messages for assignments to methods.
removed comment for resolved radar.
* removed extra line and braces
* added tests for assignment_lhs_is_apply_expression
eliminated redundant literal check which is always invoked before call
reverted 'cannot assign to value' for literal assignments in subexpressions
* Complemented assigning to literal tests & reverted to 'cannot asign to value' for methods (was 'cannot assign to member')
* removed extra tabs
* eliminated one more accidental spacing
* Update CSDiag.cpp
* added highlighting, fixed & rechecked tests
* added highlighting for complex expressions involving assigning to literals
Resolves: [SR-7445](https://bugs.swift.org/browse/SR-7445)
A corner-case left over from an earlier fix that made exhaustiveness
checker aware of irrefutable coercions. If the coercion occured as part
of a sub-pattern, that pattern would be projected with the wrong type
and would fail the intersection test. Project the pattern with the type
of the scrutinee instead.
Projection assumed if it ever hit a case where an argument pattern
contained extra parentheses that the user was trying to create
a var pattern to bind the entire argument tuple.
enum Foo {
case bar(Int, String, Float)
}
switch fooVal {
case bar(let x): ...
}
This breaks in the presence of tuple patterns with extra parentheses.
Treat these patterns explicitly when projecting them.
Ensure that we use the correct python to run the python based tools.
This also allows these tools to run on Windows which will not
necessarily associate the python script with an interpreter (python).
Note that I said "warnings"; we're going to be more cautious about
rollout and just make this a warning in Swift 5 mode, with /no/
diagnostics in Swift 3 and 4. Users are still free to use `@unknown
default` in these modes, and they'll get a fatal run-time error if
they don't and an unexpected case actually shows up.
rdar://problem/29324688
By formalizing ReferenceOwnership as a diagnostic argument kind, we get
less boilerplate, better type safety, better output consistency, and
last but not least: future proofing.
Since 'private' means "limit to the enclosing scope (and extensions
thereof)", putting it on a member means that the member can't be
accessed everywhere the type might show up. That's normally a good
thing, but it's not the desired effect for synthesized members used
for derived conformances, and when it comes to class initializers this
actually violates AST invariants.
rdar://problem/39478298
At one point compiler wouldn't let you use them in matches, so people have
had to use catch-all cases instead. SILGen already handles this because of
@_downgrade_exhaustivity_check, as well as non-exhaustive enums in
Swift 4 mode.
rdar://problem/33246586
Continue to emit notes for the candidates, but use different text.
Note that we can emit a typo correction fix-it even if there are
multiple candidates with the same name.
Also, disable typo correction in the migrator, since the operation
is quite expensive, the notes are never presented to the user, and
the fix-its can interfere with the migrator's own edits.
Our general guidance is that fix-its should be added on the main
diagnostic only when the fix-it is highly likely to be correct.
The exact threshold is debateable. Typo correction is certainly
capable of making mistakes, but most of its edits are right, and
when it's wrong it's usually obviously wrong. On balance, I think
this is the right thing to do. For what it's worth, it's also
what we do in Clang.
A protocol extension of a private protocol can define internal
or public members. We should not be able to find these members
from another file or module if an internal or public type
conforms to the protocol.
Fixes <rdar://problem/21380336>.
- Combine the common logic for editor mode and non-editor mode.
- Do a better job minimizing fix-its.
- If '@unknown' is the only missing case, put `fatalError()` in the
Xcode placeholder, since that's what the compiler would have done.
