This lets us disambiguate the symbols for static and instance properties, and enables us to eventually leave the useless "self" type mangling out of method symbols. Fixes rdar://19012022 and dupes thereof, including crasher #1341.
Swift SVN r25111
The materializeForSet accessor for a `dynamic` property needs to dynamically invoke the getter and setter of the property in order to allow for runtime modification, so it doesn't need to be dynamically dispatched itself. If the property came from an imported ObjC class, then we can't dynamically dispatch it without polluting the selector namespace. Introduce a new 'ForcedStaticDispatch' bit and set it in order to force `dynamic` materializeForSet accessors to be statically dispatched. (They can't be `final` because it's legal to override a dynamic property.) If the property came from ObjC, register materializeForSet as an external declaration so it gets generated by SIL. Fixes rdar://problem/18706056.
Swift SVN r24930
Local type declarations are saved in the source file during parsing,
now serialized as decls. Some of these may be defined in DeclContexts
which aren't Decls and previously weren't serialized. Create four new
record kinds:
* PatternBindingInitializer
* DefaultArgumentInitializer
* AbstractClosureExpr
* TopLevelCodeDecl
These new records are used to only preserve enough information for
remangling in the debugger, and parental context relationships.
Finally, provide a lookup API in the module to search by mangled name.
With the new remangling API, the debugging lifecycle for local types
should be complete.
The extra LOCAL_CONTEXT record will compressed back down in a
subsequent patch.
Swift SVN r24739
Rather than keeping just a "main class" in every module, track the "main file"
that's responsible for producing the module's entry point. This covers both
main source files and files containing classes marked @UIApplicationMain or
@NSApplicationMain.
This should have no functionality change, but is preparation for the next
commit, where we will preserve some of this information in serialization.
Swift SVN r24529
- Addresses many common user-reported "expression too complex" bugs, including rdar://problem/18876786.
- Shaves up to 10% off of the total time to run our unit tests. (Unscientifically measured on my iMac: 427.46s before, 385.17s after.)
Swift SVN r24514
Changing the design of this to maintain more local context
information and changing the lookup API.
This reverts commit 4f2ff1819064dc61c20e31c7c308ae6b3e6615d0.
Swift SVN r24432
rdar://problem/18295292
Locally scoped type declarations were previously not serialized into the
module, which meant that the debugger couldn't reason about the
structure of instances of those types.
Introduce a new mangling for local types:
[file basename MD5][counter][identifier]
This allows the demangle node's data to be used directly for lookup
without having to backtrack in the debugger.
Local decls are now serialized into a LOCAL_TYPE_DECLS table in the
module, which acts as the backing hash table for looking up
[file basename MD5][counter][identifier] -> DeclID mappings.
New tests:
* swift-ide-test mode for testing the demangle/lookup/mangle lifecycle
of a module that contains local decls
* mangling
* module merging with local decls
Swift SVN r24426
a non-native owner. This is required by Slice, which
will use an ObjC immutable array object as the owner
as long as all the elements are contiguous.
As part of this, I decided it was best to encode the
native requirement in the accessor names. This makes
some of these accessors really long; we can revisit this
if we productize this feature.
Note that pinning addressors still require a native
owner, since pinning as a feature is specific to swift
refcounting.
Swift SVN r24420
Change all the existing addressors to the unsafe variant.
Update the addressor mangling to include the variant.
The addressor and mutable-addressor may be any of the
variants, independent of the choice for the other.
SILGen and code synthesis for the new variants is still
untested.
Swift SVN r24387
use a thin function type.
We still need thin-function-to-RawPointer conversions
for generic code, but that's fixable with some sort of
partial_apply_thin_recoverable instruction.
Swift SVN r24364
Previously, this storage required that alignof(void *) >= alignof(Decl). This is
true on 64-bit platforms, where these are both 8, but on 32-bit platforms
alignof(void *) is only 4.
This now allocates enough bytes to match the alignment of the Decl in question.
This does mean that a void * must fit in that alignment, but this is true on 32-
and 64-bit platforms, and a static_assert ensures that this is true at compile
time.
As part of this change, the logic for allocating memory for a Decl has been
refactored into a separate function, so that the logic for allocating space for
a ClangNode can be centralized.
Swift SVN r23990
initializer but has no "parent" PatternBindingDecl or Pattern (i.e.
paramdecls). This is currently set on decls in the pattern of
foreach loops and case patterns, but I'll add it to other places I
find as well.
NFC since this bit is only set and not read, just more yak shaving.
Swift SVN r23910
Include a mapping from Objective-C selectors to the @objc methods that
produce Objective-c methods with those selectors. Use this to lazily
populate the Objective-C method lookup tables in each class. This makes
@objc override checking work across Swift modules, which is part of
rdar://problem/18391046.
Note that we use a single, unified selector table, both because it is
simpler and because it makes global queries ("is there any method with
the given selector?") easier.
Swift SVN r23214
@objc methods, initializers, deinitializers, properties, and
subscripts all produce Objective-C methods. Diagnose cases where two
such entities (which may be of different kinds) produce the same
Objective-C method in the same class.
As a special exception, one can have an Objective-C method in an
extension that conflicts with an Objective-C method in the original
class definition, so long as the original class definition is from a
different model. This reflects the reality in Objective-C that the
category definition wins over the original definition, and is used in
at least one overlay (SpriteKit).
This is the first part of rdar://problem/18391046; the second part
involves checking that overrides are sane.
Swift SVN r23147
Generic function signatures were including outer generic parameters,
but generic type signatures were not. This is a small part of the
problem with nested generics (in general), but also a useful cleanup
for generic signatures.
Swift SVN r23011
This commit changes ASTWalker to preserve AbstractFunctionDecl body kinds. When
walking over an AbstractFunctionDecl, ASTWalker calls setBody() on the
declaration to update the body after traversal. Prior to this commit, setBody()
would unconditionally set the body kind to BodyKind::Parsed --- that is,
traversing the AST would change the body kind to Parsed. In some cases, this
modified a body kind from TypeChecked to Parsed, causing a small number of
standard library functions to be type checked twice. This behavior also
interferes with the creation of type refinement contexts for variable accessor
functions (coming in a future commit).
This commit adds an additional parameter to setBody() that allows callers to
provide a body kind (this defaults to Parsed) and changes ASTWalker to preserve
the body kind when walking a AbstractFunctionDecl.
Swift SVN r22607
properties.
The main design change here is that, rather than having
purportedly orthogonal storage kinds and has-addressor
bits, I've merged them into an exhaustive enum of the
possibilities. I've also split the observing storage kind
into stored-observing and inherited-observing cases, which
is possible to do in the parser because the latter are
always marked 'override' and the former aren't. This
should lead to much better consideration for inheriting
observers, which were otherwise very easy to forget about.
It also gives us much better recovery when override checking
fails before we can identify the overridden declaration;
previously, we would end up spuriously considering the
override to be a stored property despite the user's
clearly expressed intent.
Swift SVN r22381
semantically valid way.
Previously, this decision algorithm was repeated in a
bunch of different places, and it was usually expressed
in terms of whether the decl declared any accessor
functions. There are, however, multiple reasons why a
decl might provide accessor functions that don't require
it to be accessed through them; for example, we
generate trivial accessors for a stored property that
satisfies a protocol requirement, but non-protocol
uses of the property do not need to use them.
As part of this, and in preparation for allowing
get/mutableAddressor combinations, I've gone ahead and
made l-value emission use-sensitive. This happens to
also optimize loads from observing properties backed
by storage.
rdar://18465527
Swift SVN r22298
There are a lot of different ways to interpret the
"kind" of an access. This enum specifically dictates
the semantic rules for an access: direct-to-storage
and direct-to-accessor accesses may be semantically
different from ordinary accesses, e.g. if there are
observers or overrides.
Swift SVN r22290
Use this in calls to TypeBase::getTypeOfMember() that were relying on
archetypes solely because they were using EnumElementDecl::getArgumentType().
Swift SVN r22205
body of a function twice.
This is almost taken care of by careful ordering, but it gets
all screwed up by synthesized accessor functions. Just give
up and keep a bit.
Swift SVN r22019
This is a simple, trivialy, not-even-half-way-there solution to weak
leaking of Objective-C classes introduced after the deployment
target. It only works for Objective-C classes and C global variables
that Clang consideres to be "weak imported". However, this bare
minimum should be enough to develop an app (by jumping through various
hoops) that uses new functionality when its
available. <rdar://problem/17296490>, which I've restricted in scope
to capture this.
Swift SVN r20956
The eventual goal for extensions of generic types is to require them
to specify their generic parameters, e.g.,
extension Array<T> { ... }
rather than today's
extension Array { ... }
Start parsing (optional) generic parameters here, and update the
representation of ExtensionDecl to accomodate this new grammar
production. Aside from the parser changes, there's no intended
functionality change here.
Swift SVN r20682
This adds generic parameters and generic signatures to extension
declarations. The actual generic parameters just mirror what is
available on the extended type; however, it is filled in via extension
validation, which is handled lazily.
This is a NFC step toward decoupling the archetypes of extensions from
the archetypes of the extended types <rdar://problem/16974298>.
Swift SVN r20675
Previously, we were just storing setter accessibility via the accessibility
level on the setter function. However, some Stored properties never actually
have a setter synthesized, which led to the compiler dropping the setter
accessibility at serialization time. Rather than try to hack up something
clever, just store the setter accessibility explicitly in every
AbstractStorageDecl. (We still only serialize it for VarDecls, because
settable SubscriptDecls always have setter functions.)
<rdar://problem/17816530>
Swift SVN r20598
This implements the logic of storing "absent" values as 0 and "present"
values as the enumerator's underlying value plus 1. For enums whose raw
values are arbitrary or small, this is a safe, space-efficient way to add
the "absent" value.
The type has been designed to be used with PointerIntPair, so it converts
(explicitly) to intptr_t, and (explicitly) from any integral type.
Adopt this for use with the Accessibility bits in a ValueDecl.
No intended functionality change.
Swift SVN r20597
it indirectly through another pointer from Decl, just embed DeclAttributes
directly into Decl and get rid of the "getMutableAttrs" nonsense.
Swift SVN r20216
