Note that if the typealias type is an internal one it will show up undeclared in the interface.
We currently allow this to avoid unintentionally hiding a public API.
Swift SVN r18627
-Hide vars that have a private type.
-Hide functions that have a parameter with private type or a parameter name with leading underscore.
-Minor change in StringUTF16.swift to avoid printing "func generate() -> IndexingGenerator<_StringCore>".
rdar://17027294
Swift SVN r18623
Post-WWDC, we need to update the type checking process to make these kinds of infinite loops impossible without checking special flags.
Swift SVN r18598
When reparenting a closure in an @lazy initializer into the computed getter, make sure
to reparent any var/pbd decls in the capture list into the same context.
Swift SVN r18365
<rdar://problem/16264989> property not mutable in closure inside of its willSet
and:
<rdar://problem/16826319> willSet immutability behavior is incorrect
by changing how we handle immutability of an observing property within its willSet.
Instead of trying to model it as an rvalue, just model it as an lvalue (which it is)
and diagnose the problem with a warning in MiscDiagnostics.
Swift SVN r18184
Only do this when neither the first word of the keyword argument nor
the last word of the base method name is a preposition. This is the
last semantic part of <rdar://problem/16795899>.
Swift SVN r17782
We were accidentally forcing all members of a class to be instantiated in two places:
- by trying to look up an existing destructor decl in the class, and
- by adding the implicit destructor to the class, because addMember needlessly called loadAllMembers.
Fix the former problem by adding a 'has destructor' bit to ClassDecl so we can track whether the implicit destructor needs to be added without querying its members. Fix the latter by making IterableDeclContext::addMember not call loadAllMembers, and making loadAllMembers not barf when it sees existing members in the context.
Together with Jordan and JoeP's changes, this makes many interpreter tests now compile 3-20x faster.
Swift SVN r17562
This basically just means "it's a CF class" for now,
but you could imagine applying this to all sorts of
class-like types from peer runtimes that we can't
support all possible language features for.
There are quite a few language features that require
fairly deep object-model integration to implement,
like subclassing and adding polymorphic methods.
Some of those features, like final classes, are useful
to generally support as attributes, but most of
them aren't. At least in the short term, it makes
sense to have a big hammer we can hit things with.
Swift SVN r17428
Subscript declarations were still encoding the names of index
variables in the subscript type, which unintentionally made them
keyword arguments. Bring subscript declarations into the modern day,
using compound names to encode the subscript argument names, which
provides consistency for the keyword-argument world
<rdar://problem/14462349>. Note that arguments in subscripts default
to not being keyword arguments, which seems like the right default.
We now get keyword arguments for subscripts, so one can overload
subscripts on the names of the indices, and distinguish at the call
site. Under -strict-keyword-arguments, we require strictness here as well.
The IRGen/IDE/SILGen test updates are because the mangling of common
subscripts changed from accidentally having keyword arguments to not
having keyword arguments.
Swift SVN r17393
When importing an Objective-C init method or factory method into an
initializer, if the first camelCase word of the first argument name
starts with "with", drop the "with". This means that
-initWithRed:green:blue:alpha:
will get imported into Swift as
init(red:green:blue:alpha:)
as will
+colorWithRed:green:blue:alpha:
This is <rdar://problem/16795899>, hidden behind the
-implicit-objc-with flag.
Swift SVN r17271
Introduce a model where an argument name is a keyword argument if:
- It is an argument to an initializer, or
- It is an argument to a method after the first argument, or
- It is preceded by a back-tick (`), or
- Both a keyword argument name and an internal parameter name are
specified.
Provide diagnostics Fix-Its to clean up cases where the user is
probably confused, i.e.,
- "_ x: Int" -> "x: Int" where "x" would not have been a keyword
argument anyway
- "x x: Int" -> "`x: Int"
This covers the compiler side of <rdar://problem/16741975> and
<rdar://problem/16742001>.
Update the AST printer to print in this form, never printing just
a type for a parameter name because we're also going to adopt
<rdar://problem/16737312> and it was easier to move the tests once
rather than twice.
Standard library and test updates coming separately.
Swift SVN r17056
It's fairly common in Cocoa applications to do something like:
var tableView: NSTableView
func tableView(sender: NSTableView, shouldDoSomething: Int) { }
where the base name of a method is the same as the name of a
property. We lost this ability when I turned on redeclaration
checking, so bring it back <rdar://problem/16746894>.
Swift SVN r16996
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
- Change the parser to unconditionally reject @mutating and @!mutating with a fixit and
specific diagnostic to rewrite them into the [non]mutating keyword.
- Update tests.
This resolves <rdar://problem/16735619> introduce nonmutating CS keyword and remove the attribute form of mutating all together
Swift SVN r16892
(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
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
