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
The former is an obvious fix; the latter is a speed optimization when using
the Debug REPL. Running the crashing code through -i will get nearly the
same effect with verification turned on.
Swift SVN r14468
There are two parts to this:
- Import protocol properties as properties, instead of as a pair of methods.
- Fix IRGen to handle property accesses in @objc protocols.
<rdar://problem/12993073>
Swift SVN r14438
This is hidden behind the frontend flag -enable-objc-optional. Use -Xfrontend
when invoking the Swift driver.
Part of <rdar://problem/15189135>
Swift SVN r14332
Right now we have a hack to mirror ObjC protocol methods into an imported
ObjC class, because Swift's lookup only looks into superclasses, not into
protocols (by default, anyway). This already isn't great because it's wrong
for @optional, but it was particularly bad if /two/ superclasses conformed
to the same protocol (directly or indirectly). Because the mirrored methods
weren't marked as overrides, the type checker would consider them both as
possibilities, leading to strange errors like this:
<REPL Input>:1:1: error: ambiguous use of 'description'
w.description()
^
AppKit.NSWindow:268:8: note: found this candidate
func description() -> String
^
ObjectiveC.NSObject:72:8: note: found this candidate
func description() -> String
^
Now, we check to see if a superclass conforms to a protocol already before
mirroring its methods into the current class or category.
<rdar://problem/16102321> and possibly also <rdar://problem/16038085>
Swift SVN r14189
We will still import these as just 'Int', 'UInt', etc., but we still want to
allow users to write some of these types themselves. We now have an enum field
in MappedTypes.def to control this.
Fix-up for r14069 and <rdar://problem/16067854>
Swift SVN r14105
...rather than Int.
This handles the case where there are existing 32-bit enum constants with
the bit set, which isn't that uncommon for NS_OPTIONS declarations.
Part of <rdar://problem/15368372>, but should also fix the main issue in
<rdar://problem/15236662>.
Swift SVN r14090
More precisely, import anonymous enums with no fixed underlying type as Int
if they would have fit in a 32-bit signed integer. If not, we can't be sure
"Int" is a valid type for code that compiles for multiple architectures.
(Currently that means we'll fall back to the C type, which is probably /also/
wrong for multiple architectures. We could try to be smarter here, since we
have the number of required bits, but let's start with just this.)
Also, remove existing code that assumed that any 64-bit underlying type was
compatible with Int, which it definitely isn't any more on 32-bit platforms.
Part of <rdar://problem/15368372>
Swift SVN r14089
NSInteger and NSUInteger are such core Cocoa types that it will be clearly
documented that they're bridged to Int. However, I can easily see someone
trying to use CFIndex and not understanding why it's missing.
At some point we may want a general solution for all the mapped types
("don't use intptr_t directly; use Int"), but for now treat CFIndex
specially.
Swift SVN r14071
separately from the get/set value. There is no exposed way in the
source language to use this, and this causes shorter term annoyance.
I chose to flatten the value and indices so the value comes first.
In principle, this allows us to completely eliminate our ObjC importer
thunks. I haven't removed them though, because they might be useful
for something else.
Swift SVN r14049
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
This is needed for the implicit conformances we synthesize. Remove a
hack from TypeCheckConstraints to find swift.~= now that it's available
using normal lookup.
<rdar://problem/15410928>
Swift SVN r13850
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
Change GenericFunctionType to reference a GenericSignature instead of containing its generic parameters and requirements in-line, and clean up some interface type APIs that awkwardly returned ArrayRef pairs to instead return GenericSignatures instead.
Swift SVN r13807
This eliminates a pile of extra casting when interacting with
Objective-C APIs. Addresses the majority of <rdar://problem/14044307>,
but there is still cleanup to do.
Swift SVN r13780
This is mostly useful for the standard library, whose name is going to
change to "Swift" soon. (See <rdar://problem/15972383>.) But it's good DRY.
Swift SVN r13758
SubscriptDecl is created, then the accessors are installed on it.
This allows us to create the subscript decl before the accessors
have been parsed, allowing us to build the subscript even in invalid
cases (better for later error recovery).
More importantly, this allows us to add it to Decls before calling
parseGetSet, so we can now make parseGetSet add accessors to Decls
without breaking source order (something that deeply upsets the IDE
features).
With all this untangled, we can now remove the 'addAccessorsInOrder'
hack where we parsed the accessors and then later tried to figure out
which order they came for the purpose of linking up the AST: accessors
now work just like everything else.
Swift SVN r13708
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
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
Also, disallow creating Modules and FileUnits on the stack. They must always
live as long as the ASTContext.
<rdar://problem/15596964>
Swift SVN r13671
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
Allow IfStmts and WhileStmts to have as their condition either an expression, as usual, or a pattern binding introduced by 'var' or 'let', which will conditionally bind to the value inside an optional. Unlike normal pattern bindings, these bindings require an in-line initializer, which will be required to be Optional type. Parse variable bindings in this position, and type-check them by requiring an Optional on the right-hand side and unwrapping it to form the pattern type. Extend SILGen's lowering of if and while statements to handle conditionally binding variables.
Swift SVN r13146
This keeps us from having to deal with fat swiftmodules for now.
In the long run we're hoping to solve this problem with build configurations,
so that a single module file can support multiple architectures.
(See <rdar://problem/15056323>)
<rdar://problem/15204953>
Swift SVN r13135
Currently only inline functions referenced from Swift source files, or
from the REPL, will get IR generated for them. Inline functions
referenced by other inline functions will require additional effort to
generate properly.
With this change we use the clang::CodeGenerator-created llvm::Module
for all IR generation in Swift. This is perhaps undesirable, but
unavoidable given the interface the public Clang APIs expose, which do
not allow for building a ModuleBuilder that borrows an existing
llvm::Module.
Also unfortunate is the hack to generate a UsedAttr for each imported
inline function, but the public Clang APIs do not provide a way to only
emit deferred decls without emitting other things (e.g. module flags
that conflict with what the Swift IRGen emits). Note that we do not do
IRGen for every inline function in the module - only the ones that the
importer pulls in, which appears to be only those transitively
referenced from Swift code.
Swift SVN r13134
