Fixes
<rdar://problem/16438738> Ensure that RawOptionSet conformance is printed for
imported NS_OPTIONS
and probably other latent bugs.
Swift SVN r16971
This restructures IfConfigDecl/Stmt to be a list of clauses controlled
by a condition. This makes it straight-forward to drop in #elseif support.
While I'm in here, this patch moves checking for extraneous stuff at the
end of the #if line from the lexer to the parser. This means that you can
now put a comment on the same line as a #if/#else/#elseif/#endif.
Swift SVN r16912
(and a similar issue for subscripts)
In Cocoa, a property can be declared readonly in the public interface of a
class and readwrite in a class extension. Similarly, a protocol can require
a readable property, but a category then declares the property as readwrite.
Swift doesn't like having two of the same declaration, and which one ended
up being used was order-dependent.
This change doesn't really fix the problem, but it does paper over it.
Now, when the importer sees a redeclaration of a readonly property as
readwrite, it forcibly updates the existing property with the new setter.
This isn't entirely correct; the redeclaration doesn't show up in its category,
and this doesn't respect visibility (i.e. the change to readwrite occurs in
a separate module that isn't visible in all source files). (But extensions
don't respect visibility in any other way, either, even in pure Swift code.)
At its heart, this is just a mismatch between Objective-C allowing
redeclarations that add capabilities and Swift not having redeclarations
at all. At some point, it may make more sense to model this as an overload,
or to mark the original declaration invalid, but for now this seems to be
the most contained change we can get that fixes the problem.
<rdar://problem/16692921>
Swift SVN r16832
Perform redeclaration checking of global and type-member declarations
at the time of declaration, using a notion of the signature of a
declaration to determine when one declaration is a redeclaration of
another. See ValueDecl::getOverloadSignature() and
conflicting(OverloadSignature, OverloadSignature) for the specific
rules we implement. In a nutshell:
- For functions, the signature includes:
+ The full name (which includes argument names)
+ The interface type
+ Whether the function is a class/static or instance method
+ For an operator, whether it is prefix or postfix
- For a subscript, the signature is the interface type
- For everything else, the signature is just the name
This tightens the rules in a number of ways, which is reflected in the
test case churn:
- We now properly perform redeclaration checking for generics
- We now propertly handle API argument names for functions
- We now ban overloading between two variables of the same name but
different type
- We now ban overloading between a variable/property and a function
- We now ban overloading for initializers
The two test cases of actual interest are:
test/decl/overload.swift: A bunch of new test cases for our checking
test/Constraints/members.swift: I commented out a useful test for
now, because it relies on overloading between a property and a
function. We can reconsistute this test with a couple of modules.
This commit fixes at least a half dozen radars under the umbrella
<rdar://problem/11212777>. I still need to check them individually to
close them out.
Swift SVN r16691
The selector-style parameter parsing code is going away "soon", but we
still need to prop it up a bit longer. Hence, I don't feel too bad
about the Parser-level state I'm using in this hack to make it happen.
With that change, we can now establish two important invariants in the
AST:
- Only parameters (ParamDecl or GenericTypeParamDecl) can have their
DeclContexts changed. Everything else comes into being in the
correct context.
- All of the parameters in a function/constructor/closure/etc. are
described by ParamDecls, not just VarDecls.
Swift SVN r16593
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 use of ASTContext-allocated arrays to store the members of nominal
type declarations and the extensions thereof is an
abomination. Instead, introduce the notion of an "iterable"
declaration context, which keeps track of the declarations within that
context (stored as a singly-linked list) and allows iteration over
them. When a member is added, it will also make sure that the member
goes into the lookup table for its context immediately.
This eliminates a ton of wasted memory when we have to reallocate the
members arrays for types and extensions, and moves us toward a much
more sane model. The only functionality change here is that the Clang
importer no longer puts subscript declarations into the wrong class,
nor does it nested a C struct within another C struct.
Swift SVN r16572
NFC. DeclRange is a range over DeclIterators, and is used rather than
ArrayRef<Decl*> to retrieve the members of a nominal type declaration
or extension thereof. The intent is to change the representation of
DeclRange next.
Swift SVN r16571
We're going to want these various adaptors, and helpers built on top
of them, when we replace the array-based storage of members in nominal
types and extensions with something more sane.
Swift SVN r16569
Basically, if an imported enumeration case is referenced without qualification as an argument to a '==' application (E.g., "foo.bar == .Baz"), and the enumeration type had not previously been resolved, overloads to '==' will be added to the global scope while performing overload resolution. This means the overloads will be ignored while solving for that application, but will be available for subsequent applications. (So you'll get an "expression does not type check" error the first time around, but not for subsequent applications of '==' to that enumeration type.)
The Equatable protocol is rather lightweight, however, and adding it to imported types directly results in no meaningful overhead to type check performance; we should just add it outright. As things evolve, though, it'll be worth considering how to make the type checker more amenable to lazy declarations.
Swift SVN r16557
Factory initializers express an initializer that produces an object of
the given type, but is not inherited and not designated. Although they
have a syntactic form for presentation purposes (-> ClassName), there
is no way to specify or implement them within Swift. Rather, factory
initializers are created when importing an Objective-C factory method
that returns the class type rather than instancetype.
Swift SVN r16528
Convenience factory initializers are convenience initializers produced
by importing an Objective-C factory method as a convenience
initializer. The distinction is currently only used to eliminate the
awful layering violation I recently introduced in name lookup, which
was consulting Clang AST nodes directly. It will also be useful in
SILGen.
Swift SVN r16527
Introduce CtorInitializerKind to describe the kind of an enum, rather
than a bool, to make way for more initializer kinds in the future.
Swift SVN r16525
Formatting names into strings repeatedly, and using those for semantic
analysis, is generally considered poor form. Additionally, use the
camelCase utilities to perform the string manipulation we need, and
cache results on the ObjCAttr so we don't repeatedly do string
manipulation.
Swift SVN r16334
This allows us to consistently print the AST, no matter if it was just parsed
or deserialized.
Note that we still serialize the isObjC bit from Decl, because it can be set or
cleared by the typechecker. It is possible to have isObjC=true when there is
not attribute (the ObjC'ness was inferred), and it is possible that
isObjC=false while there is an attribute (when the attribute does not pass the
semantic check). While we can represent the former with an implicit attribute,
the latter is harder to represent (maybe with an invalid bit on the attribute?)
Swift SVN r15935
Provide a fine-grained classification of declarations that can be used
in diagnostics instead of ad hoc %select operations. For now, only cut
over the "overriding a final <whatever>" diagnostic.
Swift SVN r15932
This requires some careful handling since the base of an ArrayRef and the
lazy loading "context data" both have no free bits, but it now works.
(It's essentially a TwoPointerUnion type, just specialized for a particular
pair of two-pointer types.)
No functionality change, except that NominalTypeDecl and ExtensionDecl
are two words smaller.
Swift SVN r15910
This is missing almost all semantic analysis and is missing various
optimization opportunities (e.g. final methods that are not overrides
don't need vtable entries), but this is enough to devirtualize class
stuff, which is important for our performance efforts. I'll add this
to release notes when it is more fully fleshed out.
Swift SVN r15885
...then use this functionality for derived conformances for RawRepresentable.
No functionality change because these bodies are always forced right now.
Swift SVN r15828
Swift will use the basename + argument names formulation for
names. Update the DeclName interfaces, printing, and __FUNCTION__ to
use the method syntax.
We'll still need to rework the "x.foo:bar:wibble:" syntax; that will
come (significantly) later.
Swift SVN r15763
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
This significantly reduces the amount of overhead incurred when naively importing large external modules without referencing many of its members, which should directly improve response times in the playground. For example, the repro code attached to rdar://problem/16387393 imports Foundation but references none of its members, and with these changes its total compilation time is almost 2.5x faster.
Swift SVN r15479
