The semantic checks for CodingKeys are being duplicated across the value witness synthesis code paths. Just synthesize a CodingKeys enum and let validateCodingKeysEnum do the heavy lifting when we actually need to go emit diagnostics.
Swift classes cannot meaningfully conform to NSObjectProtocol.
Inheriting from NSObject is the appropriate fix, so suggest that.
Fixes rdar://problem/32543753.
This breaks source compatibility a little bit more than we'd like, so
reverting it for now.
Fixes <rdar://problem/57213598>.
This reverts commit 04fbcc0149.
Previously we did this as a last resort if inference fails. The new
behavior is technically source-breaking, but I suspect nobody
relied on the old behavior.
This can help avoid cycles by eliminating some unnecessary validation work.
Fixes <https://bugs.swift.org/browse/SR-11407>, <rdar://problem/54979757>.
If a protocol requirement has a type that's a nested member
type of another member type, eg,
protocol P {
associatedtype A : Q
func f(_: A.B)
}
Then we don't actually want to use 'f()' to infer the witness
for 'A'. By avoiding doing so, we eliminate some cycles which
can allow some programs to type check that didn't before.
* [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
Overload resolution performs a lookup rooted at a pattern binding's
initializer that scoops up the var decl bound by the pattern. This
forces it to validate the variable while type checking said variable's
initializer. The old answer to this problem was to skip validation
which returns a temporary ErrorType. We should patch lookup so it
doesn't consider these variables.
This is an amalgam of simplifications to the way VarDecls are checked
and assigned interface types.
First, remove TypeCheckPattern's ability to assign the interface and
contextual types for a given var decl. Instead, replace it with the
notion of a "naming pattern". This is the pattern that semantically
binds a given VarDecl into scope, and whose type will be used to compute
the interface type. Note that not all VarDecls have a naming pattern
because they may not be canonical.
Second, remove VarDecl's separate contextual type member, and force the
contextual type to be computed the way it always was: by mapping the
interface type into the parent decl context.
Third, introduce a catch-all diagnostic to properly handle the change in
the way that circularity checking occurs. This is also motivated by
TypeCheckPattern not being principled about which parts of the AST it
chooses to invalidate, especially the parent pattern and naming patterns
for a given VarDecl. Once VarDecls are invalidated along with their
parent patterns, a large amount of this diagnostic churn can disappear.
Unfortunately, if this isn't here, we will fail to catch a number of
obviously circular cases and fail to emit a diagnostic.
When there's a module with the same name as a type in a
different module, lookup will look into the type, not the module, when
resolving members. Until that behavior is fixed, add a note showing what
lookup was trying to look into, to make the behavior more clear.
Helps rdar://54770139
This was fixed by pull request #26174, but the test case there was
specific to property wrappers, while the fix also addresses issues
with other ambiguity name lookups such as protocol names in an
inheritance clause.
Add the request `ProtocolRequiresClassRequest` to lazily determine if a
`ProtocolDecl` requires conforming types to be a class.
Note that using the request evaluator to compute `requiresClass` introduces
cycle errors for protocol declarations, where this computation didn't
previously emit diagnostics. For now, we'll allow duplicate diagnostics in this
case, with the eventual goal of removing explicitly checking for cycles
via `checkCircularity` (instead letting the request evaluator handle cycle
diagnostics).
finalizeDecl() would kick off certain requests. This was necessary
before we had the long-lived type checker to ensure that requests
that required a type checker could be completed in time for SILGen.
It was also necessary to always emit diagnostics for declarations in
primary files.
Since we now have a long lived type checker, the first reason is no
longer valid, so we can move this work from finalizeDecl() to
typeCheckDecl(), where it will run for declarations in primary files
only.
To ensure that @objc selector conflict diagnostics still get emitted,
we also walk the superclass chain and force isObjC() to be computed
for each declaration in each superclass.
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
