We can't do this because the object was deallocated. However, ASan should flag us if we regress on touching deallocated unowned-referenced objects though, so we don't need this. rdar://problem/19677703
Swift SVN r24894
ObjC unowned references are backed by an ObjC weak reference which will eagerly deallocate the object when it's strongly released, so in an unknown-refcount situation, we can't safely dereference the object pointer to determine its Swiftness. We can, however, look at the side table of weak references; if there's an entry for this object, then it's reliably an ObjC object (or it's some other object that got allocated in the reclaimed space for the dead object, but that's a race we fundamentally can't win with this broken design). Fixes rdar://problem/18091547 (modulo the aforementioned reallocation race).
Swift SVN r24825
Instead of directly referencing a long-dead constructor from the standard library, put a purpose-built function in StdlibUnittest to feed a Swift object reference to the test C code. rdar://problem/18498737
Swift SVN r24816
clang-600 doesn't consider explicit conversion operators as satisfying
std::is_constructible, even though actually writing the construction
does work. Just don't run that part of the test if that's how
std::is_constructible behaves.
Swift SVN r24603
We don't actually check them yet, but this fits them into the same dependency
structure as intra-module dependencies.
Part of rdar://problem/19270920
Swift SVN r24335
(and similar mixed modes)
This is duplicating some of the work in swift_llvm_config, and should
probably be refactored back there at some point, but for now this gets
unit tests building in Xcode when the build configurations for LLVM and
Swift aren't the same.
Swift SVN r24257
...and some basic unit tests for it.
The purpose of this class is to track dependencies between opaque nodes.
The dependency edges are (kind, string) pairs, where the "kind"
distinguishes different kinds of dependencies (currently "top-level names"
and "types that we do lookup on"). The step is to make use of it in
running compile commands.
The YAML-based file format is only for bring-up and testing purposes.
I intend to switch it to a bitcode-based format in the long run.
Part of rdar://problem/15353101
Swift SVN r23223
This change adds infrastructure to represent inline markup in the AST,
implements parsing of some of the inline markup (*emphasis*, **strong
emphasis**, `interpreted text`, ``inline literal``), and XML generation
for these constructs for SourceKit clients to consume.
The parsing itself is incomplete for constructs not mentioned above.
Most notably, we don't parse hyperlinks, and we don't parse the
double-colon that changes the next paragraph into a literal block.
Swift SVN r22752
Metatype metadata now always refers to the maximally-abstracted @thick metatype representation, so metatypes are never trivial from the runtime's point of view.
Swift SVN r21975
constructs generic class metadata properly when the
superclass has an unexpected prefix.
Also fix a bug in the constructor for ClassMetadata (which is
only actually constructed this way in unit tests).
Swift SVN r20586
unexpected forematter from the superclass.
This requires a pretty substantial shift in the
generic-metadata allocation/initialization dance
because (1) we can't allocate class metadata without
knowing what the superclass is and (2) the offset
from the metadata cache entry to the address point is
no longer determined solely by the metadata pattern.
While I'm making invasive changes to metadata, fix
two race conditions in metadata creation. The first
is that we need to ensure that only one thread succeeds
at lazily creating a generic-metadata cache. The second
is that we need to ensure that only one thread actually
attempts to create a particular metadata; any others
should block until the metadata is successfully built.
This commit finishes rdar://17776354. LLDB will
need to adjust to the runtime-private metadata layout
changes.
Swift SVN r20537
