This is a type that has ownership of a reference while allowing access to the
spare bits inside the pointer, but which can also safely hold an ObjC tagged pointer
reference (with no spare bits of course). It additionally blesses one
Foundation-coordinated bit with the meaning of "has swift refcounting" in order
to get a faster short-circuit to native refcounting. It supports the following
builtin operations:
- Builtin.castToBridgeObject<T>(ref: T, bits: Builtin.Word) ->
Builtin.BridgeObject
Creates a BridgeObject that contains the bitwise-OR of the bit patterns of
"ref" and "bits". It is the user's responsibility to ensure "bits" doesn't
interfere with the reference identity of the resulting value. In other words,
it is undefined behavior unless:
castReferenceFromBridgeObject(castToBridgeObject(ref, bits)) === ref
This means "bits" must be zero if "ref" is a tagged pointer. If "ref" is a real
object pointer, "bits" must not have any non-spare bits set (unless they're
already set in the pointer value). The native discriminator bit may only be set
if the object is Swift-refcounted.
- Builtin.castReferenceFromBridgeObject<T>(bo: Builtin.BridgeObject) -> T
Extracts the reference from a BridgeObject.
- Builtin.castBitPatternFromBridgeObject(bo: Builtin.BridgeObject) -> Builtin.Word
Presents the bit pattern of a BridgeObject as a Word.
BridgeObject's bits are set up as follows on the various platforms:
i386, armv7:
No ObjC tagged pointers
Swift native refcounting flag bit: 0x0000_0001
Other available spare bits: 0x0000_0002
x86_64:
Reserved for ObjC tagged pointers: 0x8000_0000_0000_0001
Swift native refcounting flag bit: 0x0000_0000_0000_0002
Other available spare bits: 0x7F00_0000_0000_0004
arm64:
Reserved for ObjC tagged pointers: 0x8000_0000_0000_0000
Swift native refcounting flag bit: 0x4000_0000_0000_0000
Other available spare bits: 0x3F00_0000_0000_0007
TODO: BridgeObject doesn't present any extra inhabitants. It ought to at least provide null as an extra inhabitant for Optional.
Swift SVN r22880
at -Onone. This is currently turned off by default because it
also reports false positives, but it is an incredibly useful mechanism
to find linetable bugs.
Swift SVN r22738
<rdar://problem/18592152> Unchecked Swift builder is sometimes crashing in AsmPrinter::EmitFunctionBody
DIBuilder adds all DIVariables to a temporary named MDNode in
order to add them to the variables field in their parent
DISubprogram in DIBuilder::finalize(). In the absence of an
llvm::Function DIBuilder uses the human-readable name as a name
for this temporary MDnode, which in the case of specialized
generic functions (which are then SILinlining and thus
zombiefied, making them loose their llvm::Function) is not
unique, because the specialization is not encoded in the
human-readable name. Until either of these problems are fixed,
use the mangled name as human-readable name IR-less functions
here.
Work is underway to upstream an assertion in LLVM that will
ensure this won't regress.
Swift SVN r22687
This reverts r22625 as it breaks my
RelWithDebInfo/SWIFT_OPTIMIZED=NO/INTERNAL_CHECKS=ON build:
Assertion failed: (DS->SILFn != Parent->SILFn && "non-inlined parent scope from different function?"), function parentScopesAreSane, file swift/lib/IRGen/IRGenDebugInfo.cpp, line 383.
...
1. While emitting IR SIL function @_TFSs10minElementUSs12SequenceType_USs13GeneratorType_Ss10Comparable__FQ_QQQ_9Generator7Element for 'minElement' at /Users/dave/src/s/swift/stdlib/core/Algorithm.swift:12:8
Swift SVN r22630
Eliminate the intermediate top_level_code function. Now that SIL is expressive enough to express a "main" function, there's no reason for it, and this eliminates a bunch of mystery code in IRGen to thunk from main to top_level_code by reaching for hardcoded symbol names. Demystify the special code for setting up C_ARGC and C_ARGV by having SILGen look for a transparent "_didEnterMain" hook in the stdlib and emit a call to it.
Swift SVN r22525
This prevented dead function removal of inlined dead functions. Beside the stdlib it's mostly
an issue of SIL size (and therefore compiletime), because llvm did remove such functions anyway.
Swift SVN r22301
OpDeref to function objects (since Swift doesn't have function *pointer*
types). It confuses the debugger and is inconsistent with how we handle
other types such as classes.
<rdar://problem/18272602> Function pointers in local variables have incorrect DWARF locations
Swift SVN r21792
- Use SILFileLocations when compiling .sil with -g.
- Fix a crash when trying to find the Builtin module.
Part of <rdar://problem/17999350> `swiftc -g` crashes in some Swift tests
Swift SVN r21425
to ignore them, while still referencing the module file needed to perform
type lookups, etc.
<rdar://problem/17648201> After setting a breakpoint, the first step action is malfunctioning
Swift SVN r20801
We were already effectively doing this everywhere /except/ when building
the standard library (which used -O2), so just use the model we want going
forward.
Swift SVN r20455
This patch extends the syntax with a new #line directive that is inspired
by the homonymous CPP directive. It can be specified in all locations a #if
is legal (Stmt, Decl).
Semantics
---------
#line 42 "file.swift"
This makes diagnostics and debug information behave as if the subsequent
lines came from file.swift+42.
#line // without arguments
This switches back to the main source file and the switches back to the
normal line numbering. Any previous #line directives will result in gaps
in the main file.
Rationale
---------
LLDB and the REPL need this for making expressions that are entered into
the expression evaluator or REPL debugable. For more info see
<rdar://problem/17441710> Need #line directive or something similar so we can enhance the debugging of expressions and REPL
Also, I believe the stdlib would benefit from this and it would allow us
to get rid of the line-directive wrapper script.
Swift SVN r19384
the scope of the previous instruction.
<rdar://problem/17021591> Gap in lexical block coincides with the first line-table entry for a line => no variables at that line
Swift SVN r19318
