It's possible to construct subscript member responsible for key path
dynamic member lookup in a way which is going to be self-recursive
and an attempt to lookup any non-existent member is going to trigger
infine recursion.
Let's guard against that by making sure that the base type of the
member lookup is different from root type of the key path.
Resolves: rdar://problem/50420029
Resolves: rdar://problem/57410798
Move `buildDynamicMemberLookupIndexExpr` into
ExprRewriter, and pass the string literal through
`handleStringLiteralExpr` to properly handle its
coercion to the parameter type.
We're planning to emit these attributes in module interfaces, but until
we land that patch, we want to parse these attributes and ignore them.
Part of rdar://51249311
When a method in an extension of a class looks like an
override of a method from the base class, we emit a
diagnostic.
However due to a bug we used to skip this diagnostic for
certain members of constrained extensions.
Indeed it feels like we should not be doing this check
at all for members of constrained extensions, so lets
explicitly skip it, fixing a source compatibility problem
that was introduced when the unrelated bug was fixed.
Fixes <rdar://problem/57029805>, <https://bugs.swift.org/browse/SR-11740>.
This is just for prototyping purposes. I also had to loosen a small restriction
where semantics functions were not allowed in local contexts. There really is no
reason to enforce this and I think since it came in the first commit that
introduced semanitcs it was most likely NadavR just being conservative and
careful.
This non-user-facing attribute is used to denote pointer parameters
which do not accept pointers produced from temporary pointer conversions
such as array-to-pointer, string-to-pointer, and in some cases
inout-to-pointer.
Patch up all the places that are making a syntactic judgement about the
isInvalid() bit in a ValueDecl. They may continue to use that query,
but most guard themselves on whether the interface type has been set.
This will make it easier to prototype diagnostics on specifically marked nominal
types. My intended usage would be to have a way to emit diagnostics if specific
instances of the nominal type are ever not on the stack.
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.
Argument-to-Parameter mismatch handles conformance failures
related to arguments, so the logic in `MissingConformanceFailure`
which wasn't entirely correct is now completely obsolete.
Resolves: rdar://problem/56234611
When it comes to `@autoclosure` parameters we only detect and diagnose
mismatches related to invalid implicit conversions to pointer types. But
`@autoclosure` parameters just like regular ones can have type mismatches
as well which can be handled via recently introduced
`argument-to-parameter mismatch` fix.
