Improve the type checker to create implicit DestructorDecls, tighten the
assertion in ImplicitReturnLocation::getImplicitReturnLoc(), and add a verifier
check that a class in a type checked AST always has exactly one destructor.
SILGen used to generate a destructor if the class does not have a
DestructorDecl. SILGen used to put the ClassDecl inside the SILLocation for
the destructor SIL code. This is not a very clean solution: in this case
ImplicitReturnLocation SILLocations contain ClassDecl, which is surprising.
rdar://14970972 Implicit destructors should have AST nodes
Swift SVN r8498
This makes it impossible to call an "init" method from Swift code; one
must construct an object, delegate to another constructor (not yet
implemented), or chain to a superclass constructor.
Swift SVN r8421
When we import an Objective-C init method into Swift as a constructor,
the Clang importer currently synthesizes both a +alloc call (used by
the allocating constructor) and a body that forwards to the
corresponding init method. Eliminate the body and stop emitting an
initializing constructor at all: instead, the allocating constructor
will invoke the init method through objc_msgSend.
Swift SVN r8420
Implement the new rules for mapping between selector names and
constructors. The selector for a given constructor is formed by
looking at the names of the constructor parameters:
* For the first parameter, prepend "init" to the parameter name and
uppercase the first letter of the parameter name. Append ':' if
there are > 1 parameters or the parameter has non-empty-tuple type.
* For the remaining parameters, the name of each parameter followed
by ':'.
When a parameter doesn't exist, assume that the parameter name is the
empty string.
And, because I failed to commit it separately, support selector-style
declarations of constructor parameters so that we can actually write
constructors nicely, e.g.:
// selector is initWithFoo:bar:
constructor withFoo(foo : Foo) bar(bar : Bar) { ... }
Swift SVN r8361
AnyFunctionRef is a universal function reference that can wrap all AST nodes
that represent functions and exposes a common interface to them. Use it in two
places in SIL where CapturingExpr was used previously.
AnyFunctionRef allows further simplifications in other places, but these will
be done separately.
Swift SVN r8239
While we don't really want people using NSZone, it's nice to distinguish
it from a generic void pointer, and we also currently don't have any way
to implement NSCopying without it.
<rdar://problem/14496990>
Swift SVN r8125
Fixes two bugs in Clang importer and deserialization code that were found by
the verifier:
(1) FuncExprs were created with a null FuncDecl
(2) BoundGenericType that was created by Clang importer for UnsafePtr<> and
other magic types did not have substitutions.
Swift SVN r8073
ConstructorDecl::getBody() and DestructorDecl::getBody() return 'BraceStmt *'.
After changing the AST representation for functions, FuncDecl::getBody() will
return 'BraceStmt *' and FuncDecl::getFuncExpr() will be gone.
Swift SVN r8050
getDisplayDecls() was introduced for ":print_module" and works slightly differently, e.g.
it will return the decls from a shadowed clang module, since we want to display them.
Swift SVN r7909
That is, 1234 is a CInt, 1234U is a CUnsignedInt, and 1234LL is a CLongLong.
Oh, and 3.14F is a CFloat.
One caveat here is that it is not actually possible in C to write a literal
INT_MIN:
-0x80000000 is two tokens and the literal part is unsigned
(-INT_MAX - 1) is several tokens
I've simply dropped this test for now, but it might be confusing in the rare
case where an INT_MIN-like value is used as a sentinel.
<rdar://problem/13839025>
Swift SVN r7639
This was not likely an error-free change. Where you see problems
please correct them. This went through a fairly tedious audit
before committing, but comments might have been changed incorrectly,
not changed at all, etc.
Swift SVN r7631
Each nested archetype X.Y corresponds to an associated type named 'Y'
within one of the protocols to which X conforms. Record the associated
type within the archetype itself. When performing type substitutions,
use that associated type to extract the corresponding type witness
rather than looking for the type itself. This is technically more
correct (since we used the type witness for type checking), and a step
toward pulling type substitutions into the AST.
Swift SVN r7624
This isn't very efficient: it scans every decl in the Clang TU (forcing
deserialization) and filters based on the decl's enclosing module.
Moreover, since getClangModuleForDecl() currently only handles top-level
modules, all submodules get implicitly added to the top-level module...
and will /not/ match an explicit submodule request.
(This is probably close to the behavior we actually want: include decls that
are from modules that are (a) submodules and (b) re-exported by the top-level
module. We do want that extra check, though, and we would want to find things
specifically by submodule.)
Swift SVN r7602
...and use it to load frameworks and libraries in immediate modes (-i and
the REPL), replacing a walk of visible modules that checked if any imported
modules were Clang modules.
Swift SVN r7488
...instead of just those that are re-exported. This will be used for
autolinking (and probably few other places).
As part of this, we get two name changes:
(1) Module::getReexportedModules -> getImportedModules
(2) TranslationUnit::getImportedModules -> getImports
The latter doesn't just get modules-plus-access-paths; it also includes
whether or not the import is re-exported. Mainly, though, it just didn't
seem like a good idea to overload this name when the two functions aren't
really related.
No tests yet, will come with autolinking.
Swift SVN r7487
ClangImporter::create had a 'weak' attribute but it did not actually have the desired effect,
static libraries still want to link to ClangImporter::create if it is used.
Avoiding linking ClangImporter kinda "worked" because CompilerInvocation::setSDKPath was inline,
so if you didn't call it then you didn't need to link to Clang importer, but that is avoiding
ClangImporter statically, not dynamically.
You could see this by moving CompilerInvocation::setSDKPath out-of-line and then sil-opt would fail to link.
In order to have clients avoiding linking Clang, introduce NullClangImporter which just returns null for the
ClangImporter constructor function.
Swift SVN r7465
Previously, we were creating the type corresponding to
class/struct/union declarations as part of creating the declaration
node, which happens at parse time. The main problem with this (at the
moment) occurs with nested nominal types, where we'd end up with the
wrong "parent" type when the type was nested inside an extension
(because the extension hadn't been resolved at the time we accessed
the parent's type). Amusingly, only code completion observed this,
because the canonical type system hid the problem. The churn in the
code-completion tests come from the fact that we now have the proper
declared type for class/struct/union declarations within extensions.
Take a step toward order-independent type checking by setting the type
of a class/struct/union declaration in type checking when we either
find the declaration (e.g., due to name lookup) or walk to the
declaration (in our walk of the whole translation unit to type-check
it), extending the existing TypeChecker::validateTypeDecl() entry
point and adding a few more callers.
The removeShadowedDecls() hack is awful; this needs to move out to the
callers, which should be abstracted better in the type checker anyway.
Incremental, non-obvious step toward fixing the representation of
polymorphic function types. This yak has a *lot* of hair.
Swift SVN r7444
At present, this is a distinction without a difference. However, it's
a step toward detangling archetypes from the interface of a
polymorphic function.
Swift SVN r7405
Previously, TypeAliasDecl was used for typealiases, generic
parameters, and assocaited types, which is hideous and the source of
much confusion. Factor the latter two out into their own decl nodes,
with a common abstract base for "type parameters", and push these
nodes throughout the frontend.
No real functionality change, but this is a step toward uniquing
polymorphic types, among other things.
Swift SVN r7345
Dmitri pointed out that we're just bloating the AST context's identifier
table and not actually saving any string comparison. StringRef's == is
pretty efficient anyway.
Swift SVN r7339
This will be used to resolve properties and method calls on objects with
dynamic-lookup ("id") type. For now, this is tested in swift-ide-test
by using the -dynamic-lookup-completion option and providing a
-code-completion-token value.
Caveats/TODOs:
- As before, since we're using the global method pool, this isn't scoped by
module. We could do a per-module filter, but I don't know if that will
actually buy us much.
- Again, Clang's method pool does not include methods from protocols.
- Lookup by selector name cannot find properties with a customized getter
name. <rdar://problem/14776565>
- The Clang-side method pool is keyed by selector, but Swift wants to look
things up by method name, which maps to the first selector piece, so we
end up having to do a scan of all the selectors in the pool.
Swift SVN r7330
Caveats / TODOs:
- Since we're using the global method pool, this isn't scoped by module.
We could do a per-module filter, but I don't know if that will actually
buy us much.
- Clang's method pool does not include methods from protocols.
- This requires importing every single method found into Swift's AST just
to print them in the completion results.
Swift SVN r7329
Break cycles agressively when we find circular class inheritance. The
stronger AST invariants prevent us from having to check for loops
everywhere in the front end.
Swift SVN r7325
Loading Cocoa (Clang) triggers the loading of several other modules,
including Foundation (Clang). We want to make sure we bring in the adapter
module Foundation (Swift), so loading Cocoa currently triggers a walk of
all imported modules to check for an adapter. The problem is that
Foundation (Swift) contains some eagerly-deserialized decls, which refer
to decls in Foundation (Clang). These decls were not importing correctly
because we hadn't finished loading all the adapters -- specifically, we
hadn't yet loaded ObjectiveC (Swift). This meant SEL was loaded as
swift.COpaquePointer instead of ObjectiveC.ObjCSel.
Now, when Foundation (Swift) asks to load Foundation (Clang), we'll walk
all imported modules under Foundation (Clang) to check for an adapter
before returning, even if Foundation (Clang) is already in our system.
This probably still isn't the best way to deal with this (particularly
since the modules in the subtree will get visited twice), but it ensures
that we've loaded all necessary adapter modules before trying to import
any decls.
TLDR: Importing Cocoa now correctly imports the Swift overlay for the
ObjectiveC module, meaning SELs are correctly imported.
<rdar://problem/14759044>
Swift SVN r7293
