...rather than just assuming any initializer without a body that makes it
to SILGen is a memberwise initializer.
In the long term we want SILGen to stop handling these initializers, at
which point we can see if it makes sense to remove this body kind.
No intended functionality change.
Swift SVN r25723
This is the propagation of the hack to declare getters/setters when we
need them. It really should be centralized, but this fixes a recent
regression (rdar://problem/19941580).
Swift SVN r25721
This commit suppresses deprecation warnings for references to deprecated symbols
by climbing the DeclContext hierarchy to determine if the warning location is
inside an implicit function.
This is a quick fix to get rid of spurious warnings for deprecated enums whose
nil literal conformance is synthesized by the importer. These warnings would
occur even when user code made no apparent reference to the enum in question and
instead only referred to an imported class that itself referred to the enum in a
method signature. This quick fix intentionally drops some valid warnings
(for example, for a synthesized call to a deprecated initializer in a super
class). rdar://problem/20024980 tracks adding these special purpose warnings
back.
rdar://problem/20007266
Swift SVN r25720
If we have a C function pointer conversion, generate a thunk using the same logic we use for ObjC method thunks, and emit a pointer to that thunk as the C function pointer value. (This works for nongeneric, nonmember functions; generics will additionally need to apply generic parameters within the thunks. Static functions would need to gather the metatype as well.)
Swift SVN r25653
There are a handful of Objective-C initializers with names like
"initForMemory" that take no parameters. The Clang importer has long
been importing them with a single parameter of type (), e.g.,
init(forMemory: ())
At some point, our @objc checking got stricter and started rejecting
parameters of type (), making it impossible to define such an
initializer in Swift. Codify this case in @objc checking, fixing
rdar://problem/19973250.
Swift SVN r25611
Review feedback from Doug. We don't allow vararg tuple values anymore, but if we did, we would need additional pattern-matching logic anyway.
Swift SVN r25602
Update the locator when matching optional types in parallel fashion.
This causes the simplifyLocator() call to fail to simplify the locator
completely, and avoids the bogus diagnostic.
<rdar://problem/19836341> Incorrect fixit for NSString? to String? conversions
Swift SVN r25596
Static members are never mutating, and having them be mutating in protocols
resulted in requirement mismatches.
rdar://problem/19887250
Swift SVN r25593
At Jordan's request, add a test to ensure that we emit an error when a declaration
inside an extension is more available than the extension itself. Also change a
getContextKind() comparison + cast<> to a dyn_cast<>.
Swift SVN r25592
This commit allows @availability attributes on extensions.
Unlike other declarations, extensions can be used without referring to them
by name (they don't have one) in the source. For this reason, when checking
the available version range of a declaration we also need to check to see if it is
immediately contained in an extension and use the extension's availability if
the declaration does not have an explicit @availability attribute itself.
This commit also moves building the primary file type refinement context hierarchy
in performTypeChecking() to before we resolve extensions. Resolving extensions checks for
availability of the extended declaration, so the TRC for the extension must be constructed
before then.
Swift SVN r25589
We suppress the default initializer in cases where we'd just have a constant initialized
to nil, just like we suppress it when we have an uninitialized member.
Swift SVN r25566
This doesn't allow 'continue' out of an if statement for the same reason we don't
allow it on switch: we'd prefer people to write loops more explicitly.
Swift SVN r25565
type checking any of the members of the type being analyzed, which leads to the
really exciting task of generating (e.g.) a memberwise initializer when you don't
know what the types of the members are.
Instead, synthesize these after the members are checked, which makes the code flow
much more like the other code synthesis stuff we do, and paves the way for future
improvements. NFC except one diagnostic in an error case (due to an order-of-checking
change).
This resolves <rdar://problem/16921173> implicit constructor synthesization works without validating the members of the type
Swift SVN r25545
In a situation like::
enum Foo {
case Bar(bar: Int)
}
switch foo {
case let .Bar(bar):
use(bar)
}
It's extremely unlikely anyone expects 'bar' to have type '(bar: Int)' rather than 'Int', especially because we try to eliminate single-element tuple types pretty much everywhere else. Put in a hack so that, when we see a paren pattern as the payload subpattern of an enum case pattern, and the payload has a single-element tuple type, we transform the paren pattern into a tuple pattern, which semantically matches off the label. Fixes rdar://problem/18923473, and a lot of dupes.
Swift SVN r25541
This commit removes an unnecessary check that ensured that inferred type
parameter actuals are available. This check is unnecessary because the
declaration for any inferred actual type parameter (i.e., a generic type
argument at the callsite) must be referred to in an enclosing type refinement
context. If the inferred type is not available, this reference will cause a
diagnostic to be emitted, so we don't need to emit another diagnostic for the
inferred actual. Further, this diagnostic was potentially confusing because the
point at which we emitted the diagnostic did not directly mention the type
name (because it was inferred).
This commit also beefs up testing of diagnostics for potentially unavailable
type parameters.
Swift SVN r25540
We didn't have a consistent way to utter attributes in diagnostics, sometimes saying the
'foo' attribute is not allowed
@foo attribute is not allowed
'foo' is not allowed
@foo is not allowed
etc. Standardize on the last one, since it is clear (with the @ sign, with no quotes, with no
'attribute' word in the diagnostic) that we're talking about an attribute. Move a bunch of
diagnostics inline with this.
Swift SVN r25524
un-type-annotated AnyObject binding in "if let", and allows general
patterns in if-let.
This also reverts some unrelated QoI improvements that went in with those
patches, but I'll add those back next.
Swift SVN r25507
...i.e. the immediate superclass, rather than the class that declared the
initializer.
Test also contains Doug's suggested test fix-up for r25410.
Swift SVN r25487
This changes CSApply to propagate the noescape (and noreturn) bits into a closureexpr even
when the closure type is undergoing some sort of conversion, since the conversion doesn't
affect the semantics of these bits.
Swift SVN r25454
This commit validates @availability() attribute version ranges to ensure that
a declaration is not more available than its lexically containing scope. To do so,
we find the inner-most declaration containing an @availability attribute that itself
has an @availability attribute and check that first attribute's available
version range is contained in the enclosing declaration's available range. If not,
we emit a diagnostic.
This commit removes a FIXME for checking @availability and overrides. It appears that
the FIXME is a copy/paste to/from AttributeOverrideChecker, where it still resides.
Swift SVN r25453
If a non-static 'let' field in a struct has an initializer, its implicitly generated
memberwise initializer should not override that. Handle this by having the memberwise initializer
and default initializer use the initial value of the property instead of an argument to the init.
This would have been a lot easier if sema was synthesizing the ctor bodies instead of SILGen,
but here it is. The missing case is narrow (let (x,y) = (1,2)) and for now we just disable
implicit synthesization of the incorrect case.
Swift SVN r25424
Always perform override checking based on the Swift type
signatures, rather than alternately relying on the Objective-C
selectors. This ensures that we get consistent override behavior for
@objc vs. non-@objc declarations throughout, and we separately make
sure that the Objective-C names line up.
This also allows us to inherit @objc'ness correctly (which didn't
quite work before), including inferring the Objective-C selector/name
(the actual subject of rdar://problem/18998564).
Fixes rdar://problem/18998564.
Swift SVN r25392
When referring to a type declaration that is a member of some nominal
type, we were relying on substitution into the non-interface type,
which is silly. Use the interface type here.
Other than some type-printing differences, this should be NFC.
Slight regression in two compiler crashes that had been fixed in the
previous commit; I'll look into these shortly.
Swift SVN r25385
Previously, we were reconstructing this mapping from the "full" opened
type produced by declaration references. However, when dealing with
same-type constraints between associated types and type parameters, we
could end up with an incomplete mapping, which let archetypes slip
through. Most of the churn here is sorting out the locators we need to
use to find the opened-type information. Fixes rdar://problem/18208283
and at least 3 dupes of it that I've found so far.
Swift SVN r25375
conditional context. There is no point diagnosing it here (just like a foreach loop) because
the if/let is just unwrapping the optional in the initializer expression.
Removing this requirement eliminates a bunch of extraneous type annotations in the testsuite.
Swift SVN r25370
It doesn't make sense to try to construct a partially-imported struct elementwise in Swift. We don't know what all the fields are yet. Part of rdar://problem/19807099.
Swift SVN r25366
