functions, and make those functions memoize the result.
This memoization can be both threadsafe and extremely
fast because of the memory ordering rules of the platforms
we're targeting: x86 is very permissive, and ARM has a
very convenient address-dependence rule which happens to
exactly match the semantics we need.
Swift SVN r20381
This is very brittle against the exact order in which
attribute lists are used in the module.
None of these tests even bother verifying anything
about the actual attributes involved, so just don't
test for the attribute lists at all.
Swift SVN r20380
Run whole-module checks at the end of perform Sema, specifically
TryAddFinal. After everything has been type checked, accessibility has
been provided, and we have had a chance to see any potential
overrides, we try to add the final attribute to class members.
This ends up de-virtualizing many functions, or rather they avoid the
vtable altogether. Thus, there are many test file changes. New test
file add_final.swift. Other tests updated to either reflect the
non-virtual call, or to have public added to them.
Swift SVN r20338
a flags field, add an instance address point field, and reserve
some additional space.
This change must be coordinated with a corresponding change
to ObjC runtime bits in libarclite; without this, dynamic
subclassing features like KVO will break.
The actual contents of the new fields can change without
bothering the ObjC runtime.
Swift SVN r20183
This only tackles the protocol case (<rdar://problem/17510790>); it
does not yet generalize to an arbitrary "class" requirement on either
existentials or generics.
Swift SVN r19896
We were getting this wrong for properties introduced in class extensions, for which we currently do not emit vtable entries and so are statically dispatched. Fixes <rdar://problem/17577579>. This also incidentally fixes references to properties of generic classes, which should be dynamically dispatched, but weren't because of getDeclaredTypeOf/InContext confusion.
Swift SVN r19641
dynamicCastClass assumes that the destination type is a
Swift class type.
dynamicCastObjCClass assumes that the destination type is
an ObjC class type (represented as ObjC metadata, not type
metadata).
dynamicCastUnknownClass assumes only that the destination
type is some kind of class.
Swift SVN r18776
There's a bit of a reshuffle of the ExplicitCastExpr subclasses:
- The existing ConditionalCheckedCastExpr expression node now represents
"as?".
- A new ForcedCheckedCastExpr node represents "as" when it is a
downcast.
- CoerceExpr represents "as" when it is a coercion.
- A new UnresolvedCheckedCastExpr node describes "as" before it has
been type-checked down to ForcedCheckedCastExpr or CoerceExpr. This
wasn't a strictly necessary change, but it helps us detangle what's
going on.
There are a few new diagnostics to help users avoid getting bitten by
as/as? mistakes:
- Custom errors when a forced downcast (as) is used as the operand
of postfix '!' or '?', with Fix-Its to remove the '!' or make the
downcast conditional (with as?), respectively.
- A warning when a forced downcast is injected into an optional,
with a suggestion to use a conditional downcast.
- A new error when the postfix '!' is used for a contextual
downcast, with a Fix-It to replace it with "as T" with the
contextual type T.
Lots of test updates, none of which felt like regressions. The new
tests are in test/expr/cast/optionals.swift.
Addresses <rdar://problem/17000058>
Swift SVN r18556
The functional difference is:
ClassDecl *DeclContext::isClassOrClassExtensionContext() const {
- if (auto ctx = getDeclaredTypeOfContext())
+ if (auto ctx = getDeclaredTypeInContext())
As expected, I didn't get the sense of Of/In right, manifesting in a nasty bug.
Swift SVN r18216
Split ArchetypeTypeInfo into ClassBoundedArchetypeTypeInfo, for class-bounded archetypes, and OpaqueArchetypeTypeInfo, for fully generalized archetypes (the existing case). ClassBoundedArchetypeTypeInfo is represented using a single refcounted ObjCPointer. Implement abstraction remapping from class instances to class-bounded archetypes and back, and from class-bounded archetypes to non-class-bounded and back.
Witness tables are still generated only for opaque archetypes, so method calls on class-bounded archetypes won't work just yet.
Swift SVN r5569
