than once (at least as far as IRGenDebugInfo is concerned).
No new testcases, but it comes with new assertions.
Part of <rdar://problem/15283227> A crash in llvm's getFnAttributes when IRGen is called more than once.
Swift SVN r18214
the argument types and underlying raw types.
In the long run we'd really want to emit them as DW_TAG_variant_types.
<rdar://problem/14845818> Support enums
Swift SVN r18170
tuples and structs that are passed to a function by value.
<rdar://problem/15928331> Need to support DW_OP_piece for multi-Value variables/arguments
<rdar://problem/16599747> Variables not displayed at all in SwiftDemo02b_Closure (back again)
Swift SVN r17923
accelerator-table mangled-name logic in LLVM works as expected.
<rdar://problem/16730603> Debug info for variable of type NSError does not provide mangled name
Swift SVN r16846
This was part of the original weak design that
there was never any particular reason to rush the
implementation for. It's convenient to do this now
so that we can use it to implement Unmanaged<T> for
importing CF types.
Swift SVN r16693
for types where possible.
We use the DICompositeType's UniqueIdentifier field to store the mangled
name, the name field to store the base name and Apple-llvm will emit the
unique identifier as DW_AT_name if RunTimeLang == Swift. This way the
metadata format is compatible between swift and non-Apple clang.
As bonus, we get mangled-name-based type uniquing for swift.
<rdar://problem/16303510> apple-types accelerator table should include basename for swift types
Swift SVN r16665
Fixes a crash building Foundation.swift with
SWIFT_ASSERTS=NO
-g -O2 Foundation.swift
The following function had no debug scope:
// reabstraction thunk helper from @callee_owned (@owned Swift.UncheckedOptional<Swift.String>, @unowned C._NSRange, @unowned C._NSRange, @owned Swift.CMutablePointer<ObjectiveC.ObjCBool>) -> (@unowned ()) to @callee_unowned @objc_block (@unowned Swift.UncheckedOptional<ObjectiveC.NSString>, @unowned C._NSRange, @unowned C._NSRange, @unowned Swift.UnsafePointer<ObjectiveC.ObjCBool>) -> (@unowned ())
sil shared [transparent] @_TTRXFo_oGSQSS_dVSC8_NSRangedS_oGVSs15CMutablePointerV10ObjectiveC8ObjCBool__dT__XFdCb_dGSQCSo8NSString_dS_dS_dGVSs13UnsafePointerS2___dT__ : $@cc(cdecl) @thin
Swift SVN r16496
Blocks need to be born on the stack, so we need a way to represent that on-stack storage. @block_storage T will represent the layout of a block that contains storage for a capture of type T.
Swift SVN r16355
These bits are orthogonal to each other, so combine them into one, and diagnose attempts to produce a type that's both. Spot-fix a bunch of places this revealed by inspection that we would have crashed in SILGen or IRGen if blocks were be handled.
Swift SVN r16088
modules on LLVM/trunk.
This should fix most open module related bugs and in a way that is
compatible with upstream LLVM.
<rdar://problem/16539726> Fix debug info for modules after LLVM r205685
<rdar://problem/16504765> Emit DW_TAG_namespace entry for the current module into DWARF
Swift SVN r16086
Language features like erasing concrete metatype
values are also left for the future. Still, baby steps.
The singleton ordinary metatype for existential types
is still potentially useful; we allow it to be written
as P.Protocol.
I've been somewhat cavalier in making code accept
AnyMetatypeType instead of a more specific type, and
it's likely that a number of these places can and
should be more restrictive.
When T is an existential type, parse T.Type as an
ExistentialMetatypeType instead of a MetatypeType.
An existential metatype is the formal type
\exists t:P . (t.Type)
whereas the ordinary metatype is the formal type
(\exists t:P . t).Type
which is singleton. Our inability to express that
difference was leading to an ever-increasing cascade
of hacks where information is shadily passed behind
the scenes in order to make various operations with
static members of protocols work correctly.
This patch takes the first step towards fixing that
by splitting out existential metatypes and giving
them a pointer representation. Eventually, we will
need them to be able to carry protocol witness tables
Swift SVN r15716
This names the implicit argument "oldValue". Whether we keep implicit arguments or not
is a subject of debate, tracked by rdar://16268361.
Swift SVN r14819
