Factor out the code that sets up llvm::TargetOptions and SubtargetFeatures via Clang, and reuse it in immediate mode to properly set up the ExecutionEngine to be consistent with the environment we emitted code for. This makes it so that we can use code that lowers to, for instance, SSE3 intrinsics, in particular stuff like GLKit code imported from Clang.
Swift SVN r23646
Exposes an issue with our JIT setup on x86--it looks like we don't pass consistent architecture flags to the JIT, causing it to fail to select machine instrs we emitted IR thinking we had support for.
Swift SVN r23640
Fixes a crash when KVO-observed objects were reflect()ed, and the magic mirror tried to peep the artificial subclass's nonexistent nominal type descriptor. rdar://problem/19060227
Swift SVN r23628
It's not always correct to map a Swift Bool back to ObjCBool in C land, since Bool could have originally been a proper _Bool. Pass the clang::Decl down to type lowering so we can recognize this. We still don't have a great solution for block types, because there's no decl to refer to, and Swift's user-level type system erases the distinction between void(^)(_Bool) and void(^)(BOOL). However, this is enough to let us start using C APIs that traffic in _Bool.
Swift SVN r23546
Just injecting a new protocol descriptor into an already-running ObjC runtime isn't a good idea, since the runtime might have already canonized the protocol somewhere else, and it won't recognize that classes conform to protocols it doesn't know about.
Swift SVN r23313
Fixes rdar://problem/17229052
Make it clear C_ARGV var is unsafe.
Made it impossible to set the argc/unsafeArgv outside of the stdlib.
Refactored tests to not use C_ARG{C,V}.
Made C_ARG{C,V} unavailable.
Swift SVN r23249
Diagnose cases where the use of @objc will produce Objective-C methods
that end up overriding an Objective-C method in a superclass, when
that override is not properly represented as an override in the Swift
type system. This can happen when the Objective-C methods are produced
by different kinds of entities. For example:
class Super {
@objc var property: Int
}
class Sub : Super {
@objc func setProperty(property: Int) { }
}
In Swift, Sub.setProperty and Super.property are completely
unrelated. However, both produce an Objective-C instance method with
the selector "setProperty:", so we end up with unexpected overriding
behavior. Diagnose this whenever it occurs, regardless of the kind of
@objc entity that produced the Objective-C methods: initializers,
deinitializers, methods, properties, or subscripts.
Implements the rest of the intended functionality of
rdar://problem/18391046, with the caveat that there are two remaining
classes of bugs:
1) Superclasses defined in a module (or imported from a Clang
module) aren't handled properly yet; we might not see those methods.
2) We won't properly detect all of these failures when the methods
are scattered across different source files in the same module.
Swift SVN r23170
This exposes an issue with CF types. Looking up their dynamic types gives us an ObjC class, which doesn't necessarily have the same protocol conformances (and for non-bridged types is just NSObject).
Swift SVN r23153
As a stopgap till IRGen properly emits indirected class references, support direct class reference protocol conformance records. This should get us to the point we can replace the dlsym hack with the new implementation.
Swift SVN r23073
We should unique foreign struct/enum metadata the same way we do CF foreign class metadata, but for now, treat them as direct references like we do in IRGen.
Swift SVN r23072
We were missing -_tryRetain, -_isDeallocating, -allowsWeakReference and -retainWeakReference implementations on SwiftObject, so forming an ObjC weak reference to a pure Swift object always failed and produced a nil reference. Fixes rdar://problem/18637774.
This can be reapplied now that we properly call objc_destructInstance on deallocation.
Swift SVN r23070
This is mostly just a renaming of _SwiftNativeNSArray, except that we
want to add another NSArray subclass for verbatim-bridged elements, so
we want a common base class. _SwiftNativeNSArray is the name of that
new base class, to parallel the other _SwiftNativeNSXXX classes.
Swift SVN r22913
We were missing -_tryRetain, -_isDeallocating, -allowsWeakReference and -retainWeakReference implementations on SwiftObject, so forming an ObjC weak reference to a pure Swift object always failed and produced a nil reference. Fixes rdar://problem/18637774.
Swift SVN r22710
The name was not only long and unwieldy, but inconsistent with our
conscious decision to avoid the use of "elements" in APIs as mostly
redundant.
Swift SVN r22408
This fails iOS buildbot because UIColor and NSColor disagree on the
initializer's optionality. Backing out the audit decision while
investigating the solution.
Swift SVN r22192
Per API review with Ali. While we're here, give the initializer a corresponding 'rawValue' argument label, and change the associated type name to RawValue to match.
Swift SVN r21888
Eliminate the implicit conversion from NSNumber to one of its bridged
value types (Int, Float, Double, Bool, etc.). One can use "as" to
perform the conversion instead. This eliminates a class of
accepts-dubious that involve lossy conversions from NSNumber to Int.
Our eventual arc is to eliminate all of these conversions. This is a
small, high-value step along that path rdar://problem/18269449.
Swift SVN r21879
Redefine the RawRepresentable protocol to use an 'init?' method instead of 'fromRaw(Raw)', and a 'raw' get-only property instead of 'toRaw()'. Update the compiler to support deriving conformances for enums and option sets with the new protocol. rdar://problem/18216832
Swift SVN r21762
Nor is ConstFSEventStreamRef.
Unfortunately, they both get bridged to COpaquePointer, so they're not
constructible from one another--they're identical.
rdar://problem/18112747
Swift SVN r21546
The syntax being reverted added busywork and noise to the common case
where you want to say "I have the right address, but the wrong type,"
without adding any real safety.
Also it eliminated the ability to write UnsafePointer<T>(otherPointer),
without adding ".self" to T. Overall, it was not a win.
This reverts commits r21324 and r21342
Swift SVN r21424
This takes all %target-run-simple-swift and %target-run-stdlib-swift
invocations and runs them using the interpreter instead. To enable this
mode, pass --param=interpret to lit.py; you can add this flag to the
LLVM_LIT_ARGS CMake setting (which defaults to "-sv").
This doesn't support separated %target-build / %target-run steps, nor
does it work with StdlibUnittest (which uses posix_spawn to run its
subtasks). But it's a start.
<rdar://problem/17938202>
Swift SVN r21391
We don't want typos in import statements to take down the whole REPL, but we
/do/ want the REPL to be honoring fatal errors that effectively take down the
ASTContext.
This doesn't (yet) apply to the real LLDB REPL, which does not use
SourceFileKind::REPL for its input. The right option to test there is
LangOpts.DebuggerSupport, but that's currently being set for Playgrounds as
well. I've filed <rdar://problem/18090611> for LLDB to adjust their input.
Part of <rdar://problem/17994094>
Swift SVN r21383
This regresses a bit on the diagnostic when a submodule is missing, as well
as missing out on Clang's automatic typo correction, but it does avoid putting
the Clang CompilerInstance into an error state, which is important for the
REPL. It's also not entirely clear that Clang had the right behavior in this
case either---we'd get a module back, but if the particular submodule we
asked for didn't exist we might get its parent. We can revisit this later.
Prerequisite for <rdar://problem/17994094>.
Swift SVN r21333
