This is the first in a series of patches that fixes some resilience-related
issues with synthesized accessors and materializeForSet.
Previously we maintained two lists of external declarations encountered while
type checking:
- ASTContext::ExternalDefinitions
- TypeChecker::implicitlyDefinedFunctions
The former contained the following:
- Imported nominal types from Clang, so that SILGen can emit witness tables
- Functions and variables with Clang decls, so that IRGen can instruct Clang
to emit them
- Synthesized accessors
The latter contained synthesized functions for derived conformances.
Since the second list was not visible outside Sema, we relied on the Clang
importer to add the type that contained the declaration to the
ExternalDefinitions list. In practice, we only synthesized members of enums
in this manner.
Because of this, SILGenModule::emitExternalDefinitions() had special logic to
skip members of enums, since it would visit them when visiting the enum itself.
Instead, it appears that we can remove implicitlyDefinedFunctions completely,
changing usage sites to add the decl to ExternalDefinitions instead, and
simplify SILGenModule::emitExternalDefinition() a bit in the process.
Also, it looks like we never had Modules appear in ExternalDefinitions, so
assert if those come up instead of skipping them.
Parameters (to methods, initializers, accessors, subscripts, etc) have always been represented
as Pattern's (of a particular sort), stemming from an early design direction that was abandoned.
Being built on top of patterns leads to patterns being overly complicated (e.g. tuple patterns
have to have varargs and default parameters) and make working on parameter lists complicated
and error prone. This might have been ok in 2015, but there is no way we can live like this in
2016.
Instead of using Patterns, carve out a new ParameterList and Parameter type to represent all the
parameter specific stuff. This simplifies many things and allows a lot of simplifications.
Unfortunately, I wasn't able to do this very incrementally, so this is a huge patch. The good
news is that it erases a ton of code, and the technical debt that went with it. Ignoring test
suite changes, we have:
77 files changed, 2359 insertions(+), 3221 deletions(-)
This patch also makes a bunch of wierd things dead, but I'll sweep those out in follow-on
patches.
Fixes <rdar://problem/22846558> No code completions in Foo( when Foo has error type
Fixes <rdar://problem/24026538> Slight regression in generated header, which I filed to go with 3a23d75.
Fixes an overloading bug involving default arguments and curried functions (see the diff to
Constraints/diagnostics.swift, which we now correctly accept).
Fixes cases where problems with parameters would get emitted multiple times, e.g. in the
test/Parse/subscripting.swift testcase.
The source range for ParamDecl now includes its type, which permutes some of the IDE / SourceModel tests
(for the better, I think).
Eliminates the bogus "type annotation missing in pattern" error message when a type isn't
specified for a parameter (see test/decl/func/functions.swift).
This now consistently parenthesizes argument lists in function types, which leads to many diffs in the
SILGen tests among others.
This does break the "sibling indentation" test in SourceKit/CodeFormat/indent-sibling.swift, and
I haven't been able to figure it out. Given that this is experimental functionality anyway,
I'm just XFAILing the test for now. i'll look at it separately from this mongo diff.
I didn't add anything to the table, just made use of what was already there.
We have plenty of additional calls to getIdentifier that could probably benefit
from this kind of easy access as well.
This commit also removes FOUNDATION_MODULE_NAME and OBJC_MODULE_NAME from
Strings.h. Neither of these is likely to change in the future, and both
already have KnownIdentifiers equivalents in use.
No intended functionality change.
Swift SVN r29292
This is more complex than it could be if ExtensionDecl and NominalTypeDecl
had a common ancestor in the Decl hierarchy, however this is not possible
right now because TypeDecl inherits from ValueDecl.
Fixes <rdar://problem/20981254>.
Swift SVN r28941
Previously some parts of the compiler referred to them as "fields",
and most referred to them as "elements". Use the more generic 'elements'
nomenclature because that's what we refer to other things in the compiler
(e.g. the elements of a bracestmt).
At the same time, make the API better by providing "getElement" consistently
and using it, instead of getElements()[i].
NFC.
Swift SVN r26894
Currently a no-op, but effective access for entities within the current
module will soon need to take testability into account. This declaration:
internal func foo() {}
has a formal access of 'internal', but an effective access of 'public' if
we're in a testable mode.
Part of rdar://problem/17732115 (testability)
Swift SVN r26472
This changes 'if let' conditions to take general refutable patterns, instead of
taking a irrefutable pattern and implicitly matching against an optional.
Where before you might have written:
if let x = foo() {
you now need to write:
if let x? = foo() {
The upshot of this is that you can write anything in an 'if let' that you can
write in a 'case let' in a switch statement, which is pretty general.
To aid with migration, this special cases certain really common patterns like
the above (and any other irrefutable cases, like "if let (a,b) = foo()", and
tells you where to insert the ?. It also special cases type annotations like
"if let x : AnyObject = " since they are no longer allowed.
For transitional purposes, I have intentionally downgraded the most common
diagnostic into a warning instead of an error. This means that you'll get:
t.swift:26:10: warning: condition requires a refutable pattern match; did you mean to match an optional?
if let a = f() {
^
?
I think this is important to stage in, because this is a pretty significant
source breaking change and not everyone internally may want to deal with it
at the same time. I filed 20166013 to remember to upgrade this to an error.
In addition to being a nice user feature, this is a nice cleanup of the guts
of the compiler, since it eliminates the "isConditional()" bit from
PatternBindingDecl, along with the special case logic in the compiler to handle
it (which variously added and removed Optional around these things).
Swift SVN r26150
Curried function parameters (i.e., those past the first written
parameter list) default to having argument labels (which they always
have), but any attempt to change or remove the argument labels would
fail. Use the fact that we keep both the argument labels and the
parameter names in patterns to generalize our handling of argument
labels to address this problem.
The IDE changes are due to some positive fallout from this change: we
were using the body parameters as labels in code completions for
subscript operations, which was annoying and wrong.
Fixes rdar://problem/17237268.
Swift SVN r24525
Specifically, it's not when
- the conformance is being used within a function body (test included)
- the conformance is being used for or within a private type (test included)
- the conformance is being used to generate a diagnostic string
We're still a bit imprecise in some places (checking ObjC bridging), but
in general this means less of an issue for checking literals.
Swift SVN r23700
Before it was done with a big switch statement, which remained a switch until the final code.
Now it's done by getting an integer index for both enums and just doing an integer compare.
This results in a simple compare in the final code.
Note that the == function is only generated for enums without payload. Getting the integer
index of such enums is a cheap operation.
Swift SVN r23129
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
Conforming to BooleanLiteralConvertible now requires
init(booleanLiteral: Bool)
rather than
static func convertFromBooleanLiteral(value: Bool) -> Self
This posed a problem for NSNumber's conformance to
BooleanLiteralConvertible. A class needs a required initializer to
satisfy an initializer requirement, but one cannot add a required
initializer via an extension. To that end, we hack the Clang importer
to import NSNumber's initWithBool with the name
init(booleanLiteral:)
and add back the expected init(bool:) initializer in the
overlay. These tricks make NSNumber even harder to subclass, but we
don't really care: it's nearly impossible to do well anyway, and is
generally a Bad Idea.
Part of rdar://problem/18154091.
Swift SVN r21961
it indirectly through another pointer from Decl, just embed DeclAttributes
directly into Decl and get rid of the "getMutableAttrs" nonsense.
Swift SVN r20216
Introduce the new BooleanLiteralConvertible protocol for Boolean
literals. Take "true" and "false" as real keywords (which is most of the
reason for the testsuite churn). Make Bool BooleanLiteralConvertible
and the default Boolean literal type, and ObjCBool
BooleanLiteralConvertible. Fixes <rdar://problem/17405310> and the
recent regression that made ObjCBool not work with true/false.
Swift SVN r19728
No validation is done yet on whether the user-specified access control makes
sense in context, but all ValueDecls should at least /have/ accessibility now.
/Still/ no tests yet. They will be much easier to write once we're actually
enforcing access control and/or printing access control.
Swift SVN r19143
As part of this, use tail allocation to reduce the memory footprint of
TupleExprs. Use factory methods to make it easier to construct.
I'll be using this information in a follow-on patch. SourceKit
probably wants it as well.
Swift SVN r17129
As a step on the way to harmony with Cocoa, change Hashable's hashValue into a property requirement, and update the derived conformance generation to produce a computed property instead of a standalone function.
This is mostly Ted's patch, with some help from Dmitri to clean up the IDE aspects.
Swift SVN r16864
improves location information to track the label location in the AST. We
don't currently track the location of the colon, but that would be trivial
to drop in if it is interesting.
Swift SVN r16608
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
In Sema, give derived '==' definitions the module's DerivedFileUnit as their decl context instead of the more general Module, and give it a backreference to the nominal type for which it was derived.
In SILGen, visit the derived global decls associated with Clang-imported enums, and give them shared linkage. Part of fixing <rdar://problem/16264703>.
Swift SVN r14875
