This performs very conservative dependency generation for each compile task
within a full compilation. Any source file, swiftmodule, or Objective-C
header file that is /touched/ gets added to the dependencies list, which
is written out on a per-input basis at the end of compilation.
This does /not/ handle dependencies for the aggregated swiftmodule, swiftdoc,
generated header, or linked binary. This is just the minimum needed to get
Xcode to recognize what needs to be rebuilt when a header or Swift source
file changes. We can revisit this later.
This finishes <rdar://problem/14899639> for now.
Swift SVN r18045
This improves the -import-objc-header option to read decls from the header
as well. Any declaration that is not from a module will be considered to be
part of the "header module". Conversely, forward-declarations appearing in
the header will be resolved by looking through all modules responsible for
importing a header.
More of <rdar://problem/16702101>
Swift SVN r17492
THIS IS NOT READY FOR USE YET.
The new plan for mixed-source non-framework targets is that the Swift
compiler will import an Objective-C header directly, and treat the decls
and imports in that header as explicitly visible to the entire target.
This means users don't have to modularize their headers before bringing
them into Swift.
This commit adds the option and introduces the "imported headers" module
as an implicit import for the source files being compiled. It also directs
the Clang importer to process the given header (using #import, so that it
won't somehow get included twice) and watches for any module imports that
occur as a result of reading that header.
Still to come: import of decls within the header (not within any module),
and proper serialization of cross-references to the header and its imports.
Part of <rdar://problem/16702101>
Swift SVN r17218
Also, create the Clang module loader directly rather than indirecting through
a "get constructor" function. It's no longer a valid configuration to not
have a Clang importer.
Swift SVN r16862
The hardcoding of CPU settings in lib/Driver/Tools.cpp isn't at all ideal,
but it will let us limp along for now.
<rdar://problem/16641385>
Swift SVN r16861
When an Objective-C class method follows the naming convention of a
factory method, i.e., its starting words match the ending words of the
class name, import it as a convenience initializer when it also:
- Returns instancetype (i.e., dynamic Self in Swift parlance)
- Has no NSError** parameters, which indicate the potential for failures
This is under a new flag (-enable-objc-factory-method-constructors)
because it is not generally functional. However, this is a step toward
<rdar://problem/16509024>.
Swift SVN r16479
In Objective-C, any method with no arguments can be used with dot syntax, as
can any method that takes one argument whose name starts with "set". This
commit adds a frontend-only flag -enable-objc-implicit-properties to look for
"setter-like" methods that match up with "getter-like" methods to import them
as Swift properties. By default, such methods are just considered unrelated
methods.
Part of <rdar://problem/16215476>
Swift SVN r16025
When we see an unresolved @class in a Clang module, we check the class name
against the classes in the Swift module with the same name.
This unfortunately necessitates putting a reference to the active type checker
into the ClangImporter, because the class in the current Swift module hasn't
been type-checked yet. This is now being used everywhere we do a lookup.
<rdar://problem/16295994>
Swift SVN r15355
The frontend option -split-objc-selectors splits the first part of an
Objective-C selector into both a function name and the first parameter
name at the last preposition. For example, this Objective-C method:
- (NSString *)stringByPaddingToLength:(NSUInteger)newLength withString:(NSString *)padString startingAtIndex:(NSUInteger)padIndex
is imported as
func stringByPadding toLength(newLength: Int) withString(padString: String) startingAtIndex(padIndex: Int) -> String
Swift SVN r15156
This is hidden behind the frontend flag -enable-objc-optional. Use -Xfrontend
when invoking the Swift driver.
Part of <rdar://problem/15189135>
Swift SVN r14332
Clang's LookupVisibleDecls is implemented by iterating over the map of lookups,
which clearly isn't deterministic. This *shouldn't* be a problem, but it
seems our importer has non-determinism based on the order it sees decls.
For now, at least, let's make this deterministic up front so that we don't get
weird results from :print_module.
See <rdar://problem/15785883> and <rdar://problem/15799697>.
Swift SVN r12309
Now that everything is done in terms of FileUnits, we don't need LoadedModule
anymore, and now that FileUnits just use virtual dispatch, we don't need to
indirect through ModuleLoader to distinguish them.
This doesn't quite simplify as much as it could, because the next change is
going to combine TranslationUnit and Module.
Swift SVN r10836
Part of the FileUnit restructuring. A Clang module (whether from a framework
or a simple collection of headers) is now imported as a TranslationUnit
containing a single ClangModuleUnit.
One wrinkle in all this is that Swift very much wants to do searches on a
per-module basis, but Clang can only do lookups across the entire
TranslationUnit. Unless and until we get a better way to deal with this,
we're stuck with an inefficiency here. Previously, we used to hack around
this by ignoring the "per-module" bit and only performing one lookup into
all Clang modules, but that's not actually correct with respect to visibility.
Now, we're just taking the filtering hit for looking up a particular name,
and caching the results when we look up everything (for code completion).
This isn't ideal, but it doesn't seem to be costing too much in performance,
at least not right now, and it means we can get visibility correct.
In the future, it might make sense to include a ClangModuleUnit alongside a
SerializedASTFile for adapter modules, rather than having two separate
modules with the same name. I haven't really thought through this yet, though.
Swift SVN r10834
Part of the FileUnit restructuring. A serialized module is now represented as
a TranslationUnit containing a single SerializedASTFile.
As part of this change, the FileUnit interface has been made virtual, rather
than switching on the Kind in every accessor. We think the operations
performed on files are sufficiently high-level that this shouldn't affect us.
A nice side effect of all this is that we now properly model the visibility
of modules imported into source files. Previously, we would always consider
the top-level imports of all files within a target, whether re-exported or
not.
We may still end up wanting to distinguish properties of a complete Swift
module file from a partial AST file, but we can do that within
SerializedModuleLoader.
Swift SVN r10832
The goal of this series of commits is to allow the main module to consist
of both source files and AST files, where the AST files represent files
that were already built and don't need to be rebuilt, or of Swift source
files and imported Clang headers that share a module (because they are in
the same target).
Currently modules are divided into different kinds, and that defines how
decls are looked up, how imports are managed, etc. In order to achieve the
goal above, that polymorphism should be pushed down to the individual units
within a module, so that instead of TranslationUnit, BuiltinModule,
SerializedModule, and ClangModule, we have SourceFile, BuiltinUnit,
SerializedFile, and ClangUnit. (Better names welcome.) At that point we can
hopefully collapse TranslationUnit into Module and make Module non-polymorphic.
This commit makes SourceFile the subclass of an abstract FileUnit, and
makes TranslationUnit hold an array of FileUnits instead of SourceFiles.
To demonstrate that this is actually working, the Builtin module has also
been converted to FileUnit: it is now a TranslationUnit containing a single
BuiltinUnit.
Swift SVN r10830
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
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
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
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
Before this change, DeclContext of all imported decls was set to the first
imported module.
No tests now, will be tested by future code completion commits.
Swift SVN r6949
Now that we have true serialized modules, the standard library can import
the Builtin module without any special direction (beyond -parse-stdlib),
and anyone can include those modules without special direction.
Swift SVN r6752
This closes out <rdar://problem/14513108> -- sil-opt no longer depends on
ClangImporter or any Clang libraries. In theory, however, forcing a load
of a libSwiftClangImporter.dylib would allow sil-opt to process SIL files
containing Clang imports.
Swift SVN r6700
This handles both Clang’s transitive inclusion and the use of
"adapter modules" to augment the Clang modules (e.g. Foundation.swift),
at the cost of a bit more memory (used to wrap all the Clang modules
in ClangModule objects). This is paving the way for making Sema
independent of ClangImporter.
Swift SVN r6698
This involved threading it through ModuleLoader, as with all the other
module-generic callbacks. I plan to collapse a bit of the chaining, but
unfortunately not that much.
This brings back the CodeCompletion tests.
Swift SVN r6527
