attribute checking on a per attribute basis. It makes a lot more sense for a
given attribute to think about all of the decl kinds it may or may not apply to
rather than all decl kinds thinking about the cross products of attributes they
may apply to.
Start by adding a new check to reject @final in structs and enums.
Swift SVN r15925
Language features like erasing concrete metatype
values are also left for the future. Still, baby steps.
The singleton ordinary metatype for existential types
is still potentially useful; we allow it to be written
as P.Protocol.
I've been somewhat cavalier in making code accept
AnyMetatypeType instead of a more specific type, and
it's likely that a number of these places can and
should be more restrictive.
When T is an existential type, parse T.Type as an
ExistentialMetatypeType instead of a MetatypeType.
An existential metatype is the formal type
\exists t:P . (t.Type)
whereas the ordinary metatype is the formal type
(\exists t:P . t).Type
which is singleton. Our inability to express that
difference was leading to an ever-increasing cascade
of hacks where information is shadily passed behind
the scenes in order to make various operations with
static members of protocols work correctly.
This patch takes the first step towards fixing that
by splitting out existential metatypes and giving
them a pointer representation. Eventually, we will
need them to be able to carry protocol witness tables
Swift SVN r15716
For example:
func foo(a: id)
now gets a fixit to turn 'id' into 'AnyObject'.
This relies on the ClangImporter recording the translation as it
processes declarations whose types are remapped.
Swift SVN r15668
We'll need types to be convertible from multiple kinds of inouts, which currently can't be represented with protocol conformance since we only allow one protocol conformance per type per protocol. Instead just look for a magic "__inout_conversion" static method in the type; this is lame but easy, and inout conversions shouldn't be available outside of the stdlib anyway.
Swift SVN r15599
Add two new AST node types:
- InOutConversionExpr, which represents an '&x' expression that involves inout conversion. This will be a signal to SILGen not to introduce a writeback scope for the nested conversion call.
- LValueToPointerExpr, which represents the primitive '@lvalue T' to 'RawPointer' conversion that produces the argument to the inout conversion.
Build an InOutConversionExpr AST when an inout expression is resolved by a conversion to an BuiltinInOutAddressConvertible type.
Swift SVN r15594
As a use case, declare a new 'NSUInteger' (which the importer maps to 'Int'
when importing from Objective-C) and mark it unavailable with a
helpful message. This will eventually go to the Foundation overlay
once @availability is properly serialized.
There's some duplication in availability checking. That will get
consolidated as more of it gets written. It's not very comprehensive
right now.
Swift SVN r15583
assume that we know about all the optional types in play.
This isn't correct for types that can dynamically be
more optional than they appear statically, e.g. archetypes
and existentials, but it's the easiest thing to do,
and there are workarounds. I filed rdar://16374053
to handle doing the right thing.
Swift SVN r15254
Collecting all of the designated initializers into the class
definition itself gives us the complete story in one location, which
improves consistency.
Swift SVN r15088
We'll emit a stub declaration, but we shouldn't be mysterious about
it. Part of <rdar://problem/16318855> that we'll actually implement at
some later point via <rdar://problem/16331406>.
We at least shouldn't be mysterious about it
Swift SVN r15082
There are very few times where we'd want to use @class_protocol outside of
@objc, and it feels weird to tell someone coming from Objective-C that they
need to mark their already-@objc protocol as @class_protocol. Instead, just
change ProtocolDecl::requiresClass to check for @objc.
(The commit checks for /both/ @objc-the-attribute and the IsObjC flag.
This is to give the right answer before type-checking, or at least the
likely-intended answer.)
<rdar://problem/16302887>
Swift SVN r15060
Rather than simply trapping with no output, have the initializer stubs
call into a new standard library function _unimplemented_initializer
that emits a more reasonable diagnostic, containing the name of the
class, the name of the initializer, and the file/line/column where the
class itself is defined. This finishes <rdar://problem/16156996>.
Swift SVN r15049
When a particular class has no designated initializers explicitly
written or implicitly defined, complain and suggest initializers for
all of the stored properties that need them and appear to have
sensible default values. Fixes <rdar://problem/15670604>.
Swift SVN r15023
Let ArchetypeType nested types and PotentialArchetypes be bound to concrete types in addition to archetypes. Constraints to outer context archetypes still suffer type-checker issues, but constraints to true concrete types should work now.
Swift SVN r14832
likely to be a bug (e.g. calling a function when you're looking to get a closure
in the first case, missing a type case in the second case). We emit a note saying
that the warning can be silenced by adding an explicit type, e.g.:
t.swift:4:5: warning: variable 'x' inferred to have type '()', which may be unexpected
var x = print("")
^
t.swift:4:5: note: add an explicit type annotation to silence this warning
var x = print("")
^
: ()
t.swift:7:5: warning: variable 'b' inferred to have type 'AnyObject', which may be unexpected
var b = a
^
t.swift:7:5: note: add an explicit type annotation to silence this warning
var b = a
^
: AnyObject
This implements:
<rdar://problem/15263687> Diagnose variables inferenced to 'AnyObject'
<rdar://problem/16252090> Warning when inferring empty tuple type for declarations
Swift SVN r14811
Resolve selector references using compound name lookup, pushing DeclNames a bit deeper through the type-checker and diagnostics as necessary.
Swift SVN r14791
This requires that property references have an explicit "self." qualifier when in an
explicit closure expression, since self will be captured, not the property.
We don't do the same for autoclosures. The logic here is that autoclosures can't
practically be used in capturing situations anyway, since that would be extremely
surprising to clients. Further, forcing a syntactic requirement in an autoclosure
context would defeat the whole point of autoclosures: make them implicit.
Swift SVN r14676
While it would be technically sound to do this, it almost surely means
that the user forgot the '-> Self' to make this a complete object
initializer. Provide a Fix-It to add the '-> Self'.
If we ever feel like we need this behavior, we can introduce a special
syntax for it.
Swift SVN r14598
error message saying you can't do this. This resolves:
<rdar://problem/15643576> Shouldn't crash on partial application of objc method
Swift SVN r14588
If an enum has no cases with payloads, make it implicitly Equatable and Hashable, and derive default implementations of '==' and 'hashValue'. Insert the derived '==' into module context wrapped in a new DerivedFileUnit kind, and arrange for it to be codegenned with the deriving EnumDecl by adding a 'DerivedOperatorDecls' array to NominalTypeDecls that gets visited at SILGen time.
Swift SVN r14471
invalid code (the types.swift example), and a improves diagnostics in others (the
other testcase).
This is necessary but not sufficient to fix rdar://16146971.
Swift SVN r14465
