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
variables
This change allows the type checker to create member references to generic
nominals with free type variables -- see tests. This is important for code
completion, for example, swift.Dictionary.#^A^#
Fixes rdar://15980316
Swift SVN r14461
These changes add support for build and target configurations in the compiler.
Build and target configurations, combined with the use of #if/#else/#endif allow
for conditional compilation within declaration and statement contexts.
Build configurations can be passed into the compiler via the new '-D' flag, or
set within the LangOptions class. Target configurations are implicit, and
currently only "os" and "arch" are supported.
Swift SVN r14305
Emit vtable entries for abstract initializers. When we're constructing
an object using an abstract initializer based on a metatype value that
is not statically derivable, use the vtable entry to call the
subclass's allocating constructor.
Most of the IRGen work here is hacking around the lossy SILDeclRef ->
(Code|Function)Ref -> SILDeclRef conversion. I'd feel bad about this
if John hadn't already agreed to clean this up at some point.
Swift SVN r14238
This is more in line with all other modules currently on our system.
If/when we get our final name for the language, we're at least now set
up to rename the library without /too/ much trouble. (This is mostly just
a lot of searching for "import swift", "swift.", "'swift'", and '"swift"'.
The compiler itself is pretty much just using STDLIB_NAME consistently now,
per r13758.)
<rdar://problem/15972383>
Swift SVN r14001
GenericSignatures with no params or requirements are a bug, so verify that they don't happen by making GenericSignature::get return null and GenericFunctionType assert that it has a nonnull signature. Hack Sema not to try to produce nongeneric GenericFunctionTypes when a function in a local type in a generic function context is type-checked; there's a deeper modeling issue that needs to be fixed here, but that's beyond the scope of 1.0. Now that GenericSignature always has at least one subtype, its factories no longer need an independent ASTContext argument.
Swift SVN r13837
For better type safety in SILFunctionTypes, which always want canonical types, and to provide a unique place to hang information common to all equivalent generic signatures, give GenericSignatures a concept of being "canonical".
Swift SVN r13794
now that they are implicitly updated. This exposes two things:
1) we're unncessarily serializing selfdecls in ctors and dtors.
2) The index pattern of a SubscriptDecl has no sensible DeclContext that
owns variables in it.
I'll deal with the first tomorrow, I'm not sure what to do with
the second one.
Swift SVN r13703
all of their generic parameters. This simplifies logic creating them,
allowing us to eliminate all setDeclContext() calls from the parser.
While we're at it, change Parser::addVarsToScope to be a static
function in ParseStmt.cpp and dramatically cut it down since none of
its remaining clients are using most of its capabilities. It needs
to be simplified even further.
Swift SVN r13702
automatically reparent VarDecls in their arg/body patterns and
GenericParameters to themselves. These all have to be created
before the actual context decl is created and then reparented,
so we might as well have the reparenting be done by the decl
itself. This lets us take out some setDeclContext reparenting
loops from around the parser.
I'm sure that there are a lot more places they can be removed
from as well.
NFC.
Swift SVN r13701
Refactor the base PolymorphicConvention implementation to work using generic signatures and dependent types instead of GenericParamLists and archetypes, using an ArchetypeBuilder to produce representative archetypes as a convenience when we need to consider all of the requirements attached to a dependent type. In EmitPolymorphicParameters, map the dependent types into context to resolve the archetypes that should be bound in the body of the function.
Swift SVN r13685
Retrieve the getter/setter selector from the underlying Clang node,
when there is one. This allows using and overriding Objective-C
properties that have custom getters and setters (i.e., for Boolean
properties where the getter is named isPropName), which narrowly
addresses <rdar://problem/15877160>.
One cannot declare a property in Swift and give it a different
selector. That would require a more general attribute such as
<rdar://problem/16019773>.
Swift SVN r13680
The need to hide Self from AllArchetypes of a GenericParamList is (almost) defined away by @cc(witness_method); IRGen now knows how to do the right thing for witnesses regardless of their generic signature. Eliminating this special case from the AST allows us to clear up a bunch of ugly hacks that piled up elsewhere to try to accommodate that special case, and makes the prospect of moving IRGen's PolymorphicConvention to interface types more manageable.
We do need an unfortunate hack to suppress emitting associated archetypes of Self when considering an archetype as the polymorphic source for a witness, since we can't actually pass those through the witness CC without breaking ABI compatibility between generic signatures.
Swift SVN r13663
All properties are considered nonatomic. If a property comes from Objective-C,
the accessor names may be customized, so always print them out in that case.
Swift SVN r13644
parser creates the get/set decls, and sema fills them in, instead of having sema
do all the work. This makes it easier to update DeclContexts in all cases.
Swift SVN r13597
- purge @inout from comments in the compiler except for places talking about
the SIL argument convention.
- change diagnostics to not refer to @inout
- Change the astprinter to print InoutType without the @, so it doesn't show
up in diagnostics or in closure argument types in code completion.
- Implement type parsing support for the new inout syntax (before we just
handled patterns).
- Switch the last couple of uses in the stdlib (in types) to inout.
- Various testcase updates (more to come).
Swift SVN r13564
When type checking constructors, ensure that any upstream errors in the resolution of the self type are accounted for (rather than assuming that the self type is always well-formed). Not doing so can be especially problematic within the context of a type extension, since there may not even be a self type to resolve to.
Swift SVN r13506
We can now emit witness tables for conformances to protocols
containing DynamicSelf methods.
This temporarily "breaks" uses of DynamicSelf methods on
existentials. We'll come back to that.
Swift SVN r13310
with FuncDecls. This allows us to eliminate special case code for handling
self in various parts of the compiler.
This also improves loc info (debug info and AST info) because 'self' now
has a location instead of being invalid.
I also took the opportunity to factor a bunch of places creating self decls
to use similar patterns and less copy and paste code.
Swift SVN r13196
Making DynamicSelf its own special type node makes it easier to opt-in
to the behavior we want rather than opting out of the behavior we
don't want. Some things already work better with this representation,
such as mangling and overriding; others are more broken, such as the
handling of DynamicSelf within generic classes and the lookup of the
DynamicSelf type.
Swift SVN r13141
When we type check the signature of a method, determine which method
it overrides (if any) at that time. This ensures that we always have
this information for name lookup (per <rdar://problem/15932845>).
As part of this, start to make the overriding rules a little more
sane. John has worked out more of the model here, but this patch:
- Considers an Objective-C method an override of another Objective-C
method if the selectors match and the type vs. instance-ness of the
methods match. The method types are checked for consistency
(subtyping is okay).
- Diagnoses when a method overrides more than one method from a
superclass, and
- Eliminates the "cannot overload method from a superclass"
diagnostic, which is overly pedantic and oddly limiting.
Note that we lose some amount of checking here. Specifically, we don't
have a good place to check that one has not provided two different
methods that override the same superclass method. The older code did
that (somewhat), and it's not a trivial problem to solve efficiently.
This fixes the part of <rdar://problem/15597226> that is needed for
<rdar://problem/15932845>. It still doesn't handle properties,
subscripts, and undoubtedly other issues.
Swift SVN r13108
When a let decl is in an @objc class, it is converted to StoredObjC
storage. However, since it is not mutable, it should only have a getter
synthesized for it, not a setter.
Swift SVN r13096
getInterfaceSelfType, inline them into their caller. This
has the nice effect of moving getSelfTypeForContainer into
Decl.cpp instead of being in DeclContext.cpp (which never
made sense to me).
Swift SVN r12984
properties have accessors, we have an amazing property: everything that we
want to form a getter or setter for ... really has one! I suspect many things
can be simplified now, but the first on the chopping block is
StorageDecl::getGetterType (and its three friends) which is now always exactly
just getGetter()->getType().
Swift SVN r12983
