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
Build debug info for function types using the interface types of their lowered SILFunctionTypes. We can't use the archetype path to declare dependent parameter types of a generic function, since the function type can't be tied to any specific decl context, so stub them out as an UnspecifiedType for now.
Swift SVN r13722
- purge @inout from comments in the compiler except for places talking about
the SIL argument convention.
- change diagnostics to not refer to @inout
- Change the astprinter to print InoutType without the @, so it doesn't show
up in diagnostics or in closure argument types in code completion.
- Implement type parsing support for the new inout syntax (before we just
handled patterns).
- Switch the last couple of uses in the stdlib (in types) to inout.
- Various testcase updates (more to come).
Swift SVN r13564
Making DynamicSelf its own special type node makes it easier to opt-in
to the behavior we want rather than opting out of the behavior we
don't want. Some things already work better with this representation,
such as mangling and overriding; others are more broken, such as the
handling of DynamicSelf within generic classes and the lookup of the
DynamicSelf type.
Swift SVN r13141
with two kinds, and some more specific predicates that clients can use.
The notion of 'computed or not' isn't specific enough for how properties
are accessed. We already have problems with ObjC properties that are
stored but usually accessed through getters and setters, and a bool here
isn't helping matters.
NFC.
Swift SVN r12593
Lower types for SILDeclRefs from the interface types of their referents, dragging the old type along for the ride so we can still offer the context to clients that haven't been weaned off of it. Make SILFunctionType's interface types and generic signature independent arguments of its Derive the context types of SILFunctionType from the interface types, instead of the other way around. Do a bunch of annoying inseparable work in the AST and IRGen to accommodate the switchover.
Swift SVN r12536
so LLDB can find it even if nothing in the CU references it.
<rdar://problem/15776868> p 32 gives "error: use of undeclared type 'COpaquePointer'"
Swift SVN r12180
with qualifiers on it, we have two distinct types:
- LValueType(T) aka @lvalue T, which is used for mutable values on the LHS of an
assignment in the typechecker.
- InOutType(T) aka @inout T, which is used for @inout arguments, and the implicit
@inout self argument of mutable methods on value types. This type is also used
at the SIL level for address types.
While I detangled a number of cases that were checking for LValueType (without checking
qualifiers) and only meant @inout or @lvalue, there is more to be done here. Notably,
getRValueType() still strips @inout, which is totally and unbearably wrong.
Swift SVN r11727
If there's no script-mode file in a module, don't produce a top_level_code SILFunction for it, and don't consider emitting an LLVM global_ctor for it. We should never emit static constructors from user code anymore.
Swift SVN r11644
Use the 'thin' bit set by SIL to decide whether a metatype lowers to an empty type or not. In GenPoly we still need to accommodate unlowered metatypes to keep protocol witnesses limping along; hopefully that code can be killed soon. With this change we now lower @cc(witness_method) consistently for static methods.
Swift SVN r11535
typealias MyInt: ForwardIndex = Int
There is no real reason to allow this; it's just a static_assert that Int
conforms to ForwardIndex, which would be better spelled some other way.
This only applies to concrete typealiases, i.e. those that simply alias an
underlying type. Associated types can still have both inheritance clauses
and a (default) underlying type.
Swift SVN r11481
