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
This is more in line with all other modules currently on our system.
If/when we get our final name for the language, we're at least now set
up to rename the library without /too/ much trouble. (This is mostly just
a lot of searching for "import swift", "swift.", "'swift'", and '"swift"'.
The compiler itself is pretty much just using STDLIB_NAME consistently now,
per r13758.)
<rdar://problem/15972383>
Swift SVN r14001
This is needed for the implicit conformances we synthesize. Remove a
hack from TypeCheckConstraints to find swift.~= now that it's available
using normal lookup.
<rdar://problem/15410928>
Swift SVN r13850
Also, disallow creating Modules and FileUnits on the stack. They must always
live as long as the ASTContext.
<rdar://problem/15596964>
Swift SVN r13671
This keeps us from having to deal with fat swiftmodules for now.
In the long run we're hoping to solve this problem with build configurations,
so that a single module file can support multiple architectures.
(See <rdar://problem/15056323>)
<rdar://problem/15204953>
Swift SVN r13135
Hardcoding a path to a particular SDK is definitely the wrong thing to do.
Let's see how far we can get without setting a default SDK.
See discussion in <rdar://problem/14395800>
Swift SVN r12414
This can happen when importing a decl causes a new Swift module to be loaded
(because it uses one of our bridged types), which then brings in a new Clang
module. In this case we have no choice but to throw out the existing cache
and start over. We do keep a map of everything we've imported already, though,
so at least we don't have to do that part again.
This appears to make r12309 unnecessary for correctness, but it probably still
makes performance more consistent.
<rdar://problem/15785883>
Swift SVN r12336
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
Rather than append the "Proto" suffix to all imported Objective-C
protocols, which can be confusing, whitelist those protocols that we
do have to rename. Only NSObject falls into this category so far.
Fixes <rdar://problem/15741699>.
Swift SVN r11856
Although Cocoa.framework re-exports AppKit, Foundation, and CoreData, an
arbitrary library does not re-export most of its imports. Normally this
would be fine, but the Clang importer can pull in types too eagerly and
then generate thunks and wrappers for things we don't care about. At least
for now, return to the behavior of autolinking /anything/ that gets visibly
imported.
<rdar://problem/15705923>
Swift SVN r11844
Not only this creates less ASTs, but this makes the resulting AST correct (it
is invalid to have a struct and a typealias with the same name). But the
primary motivation is AST pretty-printing: we don't want to print those extra
useless typealiases.
Swift SVN r11289
"import Cocoa" exposes the Swift adapter for Foundation, so we need to make
sure to link against both Cocoa.framework and libswiftFoundation.dylib.
We don't need to link against CoreData.framework, though; that's taken care
of by Cocoa.framework.
Swift SVN r11149
This completes the FileUnit refactoring. A module consists of multiple
FileUnits, which provide decls from various file-like sources. I say
"file-like" because the Builtin module is implemented with a single
BuiltinUnit, and imported Clang modules are just a single FileUnit source
within a module.
Most modules, therefore, contain a single file unit; only the main module
will contain multiple source files (and eventually partial AST files).
The term "translation unit" has been scrubbed from the project. To refer
to the context of declarations outside of any other declarations, use
"top-level" or "module scope". To refer to a .swift file or its DeclContext,
use "source file". To refer to a single unit of compilation, use "module",
since the model is that an entire module will be compiled with a single
driver call. (It will still be possible to compile a single source file
through the direct-to-frontend interface, but only in the context of the
whole module.)
Swift SVN r10837
This started out life as a helper class, but it's been used in multiple places.
Better to just have a single copy.
No functionality change.
Swift SVN r10835
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
Swift enum cases are already namespaced to their type, but Cocoa NS_ENUM constants are manually namespaced with a common prefix, so if we imported them as-is, we'd end up with expressions like 'NSStringSearchOptions.NSStringSearchCaseSensitive'. To make this a bit nicer, look for a common prefix of camel-case words among all of the constants in the enum, and remove that prefix from the enum case names in the Swift interface.
In the case of a single enum case, we have no basis for determining a prefix, so do nothing. This case doesn't come up in the frameworks (that I can see).
Swift SVN r9993
A single swift module can correspond to multiple Clang submodules. We need to
ask the underlying clang::Decl about the owning Clang module to get the most
precise answer.
Swift SVN r9859
ASTContexts
This introduces swift::ide::CodeCompletionCache, which is a persistent code
completion result cache.
Right now REPL happens to use it (try importing Cocoa and doing code
completion), and the difference is noticeable. But completion in REPL is
still slow, because Cocoa goes through the AST Verifier on every completion
(for unknown reasons).
This commit does not implement cache invalidation yet, and it does not use
libcache to evict cache entries under memory pressure.
This commit also introduces two regressions:
- We get fewer Cocoa results that expected. Module::isModuleVisible in Clang
does not incorrectly reports that that ObjectiveC.NSObject submodule is not
visible from Cocoa.
- We are not implementing the decl hiding rules correctly. We used to rely on
visible decl lookup to do it for us, but now we have a different data structure
we have real decls from the current module and we have a text-only cache, so we
are forced to reimplement this part of name lookup in code completion.
Swift SVN r9633
Each one has a different kind of lookup cache anyway, and there's no real
reason to have them share storage at the cost of type-safety.
Swift SVN r9242
docs/Resilience.rst describes the notion of a resilience component:
if the current source file is in the same component as a module being
used, it can use fragile access for everything in the other module,
with the assumption that everything in a component will always be
recompiled together.
However, nothing is actually using this today, and the interface we
have is probably not what we'll want in 2.0, when we actually implement
resilience.
Swift SVN r9174
Semantic context describes the origin of the declaration and serves the same
purpose as opaque numeric "priority" in Clang -- to determine the most likely
completion.
This is the initial implementation. There are a few opportunities to bump the
priority of a certain decl by giving it SemanticContextKind::ExprSpecific
context that are not implemented yet.
Swift SVN r9052
