ClassDecl::getSuperclass() produces a complete interface type describing the
superclass of a class, including any generic arguments (for a generic type).
Most callers only need the referenced ClassDecl, which is (now) cheaper
to compute: switch those callers over to ClassDecl::getSuperclassDecl().
Fixes an existing test for SR-5993.
More groundwork for protocols with superclass constraints.
In several places we need to distinguish between existential
types that have a superclass term (MyClass & Proto) and
existential types containing a protocol with a superclass
constraint.
This is similar to how I can write 'AnyObject & Proto', or
write 'Proto1 & Proto2' where Proto1 has an ': AnyObject'
in its inheritance clause.
Note that some of the usages will be revisited later as
I do more refactoring and testing. This is just a first pass.
This ensures that 'Foo' always gets imported before 'Foo_Private'.
This shouldn't strictly be necessary but does end up with more
reliable results in practice.
rdar://problem/36159006
This doesn't have a specific effect now, because all of these places
are likely to only see NameAliasType, but it is refactoring with the
intent of eliminating NameAliasType entirely.
Previously (a03c40cb2c) we assumed all Swift enums were non-frozen in
ObjC, a weird choice in retrospect. Now that we actually distinguish
frozen and non-frozen enums in Swift, we can use the
'enum_extensibility' attribute to mark them as open or closed in ObjC.
Note that this only matters for Swift libraries compiled with
-enable-resilience, i.e. those that might get a new implementation at
runtime. Everyone else is now declaring a "closed" enum, matching the
behavior in Swift.
This has three principal advantages:
- It gives some additional type-safety when working
with known accessors.
- It makes it significantly easier to test whether a declaration
is an accessor and encourages the use of a common idiom.
- It saves a small amount of memory in both FuncDecl and its
serialized form.
Use the attribute to update the OptionalTypeKind used for various
decls that we print.
I added test cases to make sure we were exercising all the modified
code paths.
1) Move existing SyntaxSugarTypes under a new subclass called UnarySyntaxSugarType.
2) Make DictionaryType subclass SyntaxSugarType.
This helps improve getDesugaredType() performance by ensuring that
ImplOrContext is stored at the same field offset in memory.
This also de-boilerplates some AST walking.
The general policy has been that even if something crashes at run
time, we don't make it a hard error in Swift 4 mode (or Swift 3 mode!)
if it wasn't a hard error in Swift 4.0 (3.0). In this case, we thought
we could get away with it, and then it turns out it actually caused
some problems. (And as 2bc010681 shows, we can still make mistakes.)
This change isn't perfect because the diagnostic appears in /clients/
rather than in the module that's being compiled as Swift 4 (instead of
Swift 5). But it still means that someone who hasn't changed
/anything/ from a valid Swift 4.0 project will be able to compile
without any changes, even if they were relying on being able to call
+new when -init was unavailable for some reason.
More rdar://problem/35942058
Follow-up to 49c65facc9 to account for subclasses. An unavailable
-init makes +new unavailable, but reintroducing it in a subclass
should reintroduce +new if the root class is NSObject (where +new is
implemented).
rdar://problem/35914080
Turns out libc++ already defines compatibility typedefs in this case,
and we don't care about any other C++ stdlibs on Apple platforms at
the moment.
rdar://problem/34861807
SourceKit uses a clever pragma to automatically attach an attribute to
every declaration in the file. However, the form of this pragma (clang
attribute push) uses a parenthesized list marked with 'any', which turns
out to be a name that people sometimes use for macros. Guard against this
using the push_macro pragma (originally from MSVC), under the assumption
that anyone who supports the highly-use-specific 'external_source_symbol'
attribute probably implements this more common extension. This does make
the generated header a little uglier, but it's not like it was really
pretty to begin with.
rdar://problem/34168022
