Float32 and Float64 typealiases
This works around a defect in the type checker, where it loses sugar
from FloatLiteralType while performing type inference for more complex
expressions involving floating point types.
rdar://16770279
Swift SVN r17241
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
This will represent the return convention of imported __attribute__((objc_returns_inner_pointer)) methods. Leave it unimplemented for now until we can autorelease things sanely.
Swift SVN r16628
Use this node to capture the argument name and its source location in
the AST. We're only building these in one place at the moment; the
rest will be updated soon.
Swift SVN r16581
The cost of hacks to swift_conformsToProtocol is starting to outweigh any benefit to being principled here. We'll get a linker error now if multiple modules declare a conformance for the same type to the same protocol, but that's arguably a good thing for 1.0 anyway, since we aren't set up to get that right in other ways.
Swift SVN r16554
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
Import a selector into a Swift method name, performing splitting at
that point. Use the resulting method name to determine the argument
names of the parameters, rather than trying to chop up the selector
again. There's more refactoring to do here.
This fixes a longstanding bug where the first argument of an
Objective-C method got the internal parameter name when it should
have gotten no name at all.
Swift SVN r15850
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
Centralize the logic for figuring out what name to use for a class or
protocol in the Objective-C runtime. When the flag is enabled (it's
still disabled by default), use mangled names for all Swift-defined
classes, including those that are @objc. Note that the naming is
determined in the AST, because we're also going to use this logic when
printing an Objective-C header for Clang's consumption. The mangled
names will always start with _Tt, so they're easy to recognize and
demangle in various tools or, eventually, in the Objective-C runtime.
The new test (test/IRGen/objc_mangling.sil) is the only test of this
behavior at the moment. The other test changes are due to the
centralized logic tweaking the names of internal constants (_DATA_*,
_CATEGORY_*, etc.).
This is the majority of <rdar://problem/15506580>.
Swift SVN r15588
A short-term fix to <rdar://problem/16079822> that keeps generic overloads from creating symbol collisions without requiring a larger migration of the debugger or other tools.
Swift SVN r14353
This isn't testable yet, as it is blocked by at least two things:
1. we can't put curried functions into witness tables (rdar://16079147),
which is a problem given that subscript accessors are curried on their
index argument.
2. accessors cannot silgen is curried form, we currently die in mangling.
Swift SVN r13947
Given our constraints for 1.0, we can actually sort-of look up protocol conformances just by dlsym'ing the symbol for their protocol witness table, since we won't be implementing runtime witness table instantiation or private conformances anytime soon. To make this work for generic types, distastefully regress our mangling for protocol conformances by assuming all generic conformances are completely general to the unbound generic type and leave the generic parameters out of the mangling.
Swift SVN r13901
We allow overloads on foo(() -> T) and foo(@auto_closure () -> T) in Sema, so they need distinct manglings. Fixes <rdar://problem/16045566>.
Swift SVN r13856
Pass the context generic params for a reabstraction thunk down to getOrCreateReabstractionThunk from the enclosing function, where it can either use them to define a new thunk or ignore them if it has an equivalent thunk already. Tweak the mangling of reabstraction thunks to use the generic signature with decontextualized "from" and "to" types instead of the generic param list.
Swift SVN r13763
Make up manglings for generic signatures and their dependent GenericTypeParamTypes and DependentMemberTypes, as well as the generic signature of a GenericFunctionType or SILFunctionType. Use these to build the mangling for a SILFunctionType from its interface types.
Swift SVN r13537
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
- Int and UInt are now struct types backed by Builtin.Word. Previously they
were typealiases for Int64; Int and Int64 are now distinct types.
- Mangled names 'i' and 'u' are now Int and UInt. Int64 is mangled longhand.
- Word is a typealias for Int. It is expected to go away in the future.
- Builtin.Word is unchanged.
- CLong and CUnsignedLong are typealiases for Int and UInt.
- FixedPoint.swift is now FixedPoint32.swift and FixedPoint64.swift.
Reunifying these requires better builtins, especially for checked
conversions (rdar://15472770).
- Updated many tests, mostly because Int is no longer spelled Int64 in sil.
- One check was removed from test decl/operator/operators.swift
because it changed behavior when Int became a non-typealias
type (rdar://15934688).
Swift SVN r13109
type, so we emit them. Add mangler (and demangler) support for these.
Enhance our testcase to check to make sure that stores within these
specifiers are direct, they don't cause recursive infinite loops.
John, I picked w/W for the mangling letters, let me know if this is ok.
Swift SVN r13050
When we're using Objective-C's memory allocation, emit .cxx_construct
methods whenever we have instance variables with in-class
initializers. Presently, these methods are just empty stubs.
Swift SVN r12211
The Objective-C runtime executes the .cxx_destruct method after the
last -dealloc has executed when destroying an object, allowing the
instance variables to remain live even after the subclass's
destructor/-dealloc has executed, which is important for memory
safety. This fixes the majority of <rdar://problem/15136592>.
Note that IRGenModule::getAddrOfIVarDestroyer() contains an egregious
hack to find the ivar destructor SIL function via a linear
search. We need a better way to find SIL functions that we know exist,
because LinkEntity does not suffice.
Swift SVN r12206
This allows them to appear in argument lists of functions, enabling behavior
like this:
func test_arguments(a : Int, var b : Int, let c : Int) {
a = 1 // ok (for now).
b = 2 // ok.
c = 3 // expected-error {{cannot assign to the result of this expression}}
}
Swift SVN r11746
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
We'll need to perform name lookup based on the file-level
DeclContext*, so the module no longer suffices. No functionality
change here yet.
Swift SVN r11523
