wrapper original wrapped value expression inside of CSApply.
This prevents type checking the synthesized backing storage initializer
twice - once with the original expression and again with the placeholder.
We used to take all the captures of a local function and treat them all
as read and write usages of vars from an outer scope. Instead, let's
refactor the analysis to walk into local functions.
Property wrappers are allowed to infer the type of a variable, but this
only worked when the property wrapper was provided with an explicit
initialization, e.g.,
@WrapsAnInt() var x // infers type Int from WrapsAnInt.wrappedValue
However, when default initialization is supported by the property wrapper,
dropping the parentheses would produce an error about the missing type
annotation
@WrapsAnInt var x
Make this second case behave like the first, so that default initialization
works consistently with the explicitly-specified version.
Fixes rdar://problem/59471019.
Make the message within 80 columns width
Improve diagnostic for read-only properties
Improve diagnostic for read-only properties
Improve diagnostic for read-only properties
Revert the property wrappers part of dd51251014.
Every part of the qualified lookup stack needs to synthesize property
wrapper members, otherwise we'll be subject to the relativistic effects
of semantic lookups in different files. Besides, Codable was the main
source of cycles and circularity under the old scheme.
Resolves rdar://59531889
* [PropertyWrappers] Class property wrapper cannot have an open init, so make sure to consider that when looking for suitable wrapper inits
* [PropertyWrappers] Extract the access control check into a separate static method
Rather than mutating the parameter pattern in place and separately
return whether an error occurred, return the new pattern or NULL if an
error occurred. While here, switch over to ContextualPattern for the
input.
And get rid of that infernal "goto".
The diagnostic is still terrible, but at least we shouldn't crash.
Fixes one manifestation of <rdar://problem/57726880>.
I also filed <https://bugs.swift.org/browse/SR-11989> to track improving
the diagnostic.
Fixes rdar://problem/53678041 and rdar://problem/57676337; the former was
because we diagnosed unavailable wrappedValue at the null source location
originall, then started suppressing that diagnostic altogether. Produce a
proper diagnostic now.
With the new way of caching overloads in the
constraint system, we no longer allow different
overloads to be resolved for the same locator in
the same scope.
Adjust the property wrapper logic
so that it appends Member locator elements for
nested lookups.
Previously, property names are hidden in the whole range of the
declarations. Now, it's only hidden in its own initializer range.
rdar://problem/49697202
The computation for "is explicitly initialized" on a pattern binding
entry didn't account for explicit initialization via the property
wrapper (e.g. @Wrapper(closure: { ... })), which lead to a crash for
properties with optional type. Fixes rdar://problem/57411331.
When realizing a type like Foo<A>.Bar, we have to account for the
possibility that Bar is defined in a constrained extension of Foo,
and has generic requirements beyond those that Foo itself places
on 'A'.
Previously we only handled this for types referenced from the
constraint system as part of openUnboundGenericType(), so we were
allowing invalid types through in type context.
Add the right checking to applyGenericArguments() to close the
hole. Note that the old code path still exists in the constraint
solver; it is used for member accesses on metatype bases only.
Fixes <https://bugs.swift.org/browse/SR-10466>.
* [Sema][Diagnostics] Add fixit for warning when inferring an undesirable type
* [Sema][Diagnostics] Generalize undesirable type warning to include arrays of empty tuples
https://bugs.swift.org/browse/SR-11511
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.
Use it to provide an idealized API for the VarDecl case in validateDecl.
In reality, a lot of work is needed to rationalize the dependency
structure of this request. To start, the callers of
typeCheckPatternBinding must be eliminated piecemeal. Once that is
done, the AST should introduce pattern binding decls along all the
places where getParentStmt() used to apply.
Define a request that can be used to grab the fully validated and
type-checked form of a given pattern binding entry. Using this,
validation of pattern bindings is fully disconnected from validation of
bound variables, and cycles are now picked up by the request evaluator.
Using this, we can go clean up all the callers that are checking a bit
and calling back into typeCheckPatternBinding. It will also serve as
the basis for a request for the naming pattern for a VarDecl which will
clean that part of validateDecl.
It's possible to find a suitable overload choice for
key path application through keypath dynamic member
lookup and assertion inside `addKeyPathApplicationRootConstraint`
should account for that.
Resolves: rdar://problem/56350060
Swift 5.1's lookup for custom attributes skipped associated type
members, which allowed code like the given example to compile. To
maintain source compatibility, identify the narrow case that happens
in practice---the property wrapper is at module scope but is now
shadowed by an associated type---warn about it, and accept it.
Fixes rdar://problem/56213175.
