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 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 makes it very clear who is depending on special behavior at the
module level. Doing isa<ClangModule> now requires a header import; anything
more requires actually linking against the ClangImporter library.
If the current source file really can't import ClangModule.h, it can
still fall back to checking against the DeclContext's getContextKind()
(and indeed AST currently does in a few places).
Swift SVN r6695
importing them
Because going through the import for every code completion request is slow,
Clang code completion results are cached in the CodeCompletionContext. The
cache needs to be invalidated whenever a new Clang module is loaded. In order
to implement this, ModuleLoadListener class was added.
Swift SVN r6505
This causes the SourceLoader to recursively parse the imported module in standard
library mode, giving it access to the Builtin module.
This is all a terrible hack and should be ripped out with great victory someday, but
until we have binary modules that persist the build setting used to produce the
module, this is the best we can do.
Swift SVN r5847
binary compatible.
This enables us to import MacTypes.h types as stdlib swift types to avoid name
conflicts. We also import stdint.h types as stdlib swift types.
We can not map 'long double'-based ctypes.Float80 to swift.Float80 because size
of long double is 128 according to SysV ABI, and I compare that against what
the type name says (I did not find a way to find the size of the type).
Darwin.Float80 is a struct, so I don’t think we can import it as swift.Float80.
So with import Darwin, Float80 is still ambiguous.
I had to rename test/ClangModules/ctypes.swift ->
test/ClangModules/ctypes_test.swift because other tests do 'import ctypes',
which picks up 'ctypes.swift'.
Swift SVN r5727
This replaces the obscure, inefficient lookup into extensions with
something more straightforward: walk all of the known extensions
(available as a simple list), then eliminate any declarations that
have been shadowed by other declarations. The shadowing rules still
need to consider the module re-export DAG, but we'll leave that for
later.
As part of this, keep track of the last time we loaded extensions for
a given nominal type. If the list of extensions is out-of-date with
respect to the global generation count (which tracks resolved module
imports), ask the modules to load any additional extensions. Only the
Clang module importer can currently load extensions in this manner.
Swift SVN r5223
This keeps AST insulated from the various module-loading interfaces, which
minimizes special-casing of the differences between ClangModule and the
(upcoming) SerializedModule.
Swift SVN r5096
This paves the way for having a Swift module importer. The eventual goal
here is to eliminate all explicit uses of the Clang module loader, but
I'm not going to push too hard on that for now.
Swift SVN r5092
Unfortunately, we're replacing that hack with a different hack to work
around the complete lack of mapping from Swift source locations to
Clang source locations.
Swift SVN r4460
Move the path for the Clang headers to lib/swift/clang since that's a place swift can find them either in the build dir or in an installation. Arrange for the headers out of the Clang build dir to be installed in the Swift tree.
Swift SVN r4296
Integrating Clang's FindVisibleDecls with Swift's by importing every decl created too much per-repl-entry compile time overhead, so as a workaround, just wire completions directly to FindVisibleDecls on the clang translation unit itself. Unfortunately this means we get completions for things Swift can't import yet, but it also means we don't have to wait 30 seconds to compile every entry after doing a completion.
Swift SVN r4061
When doing name lookup into a Clang module, look for a macro with the given name and try to convert it into a Swift decl. Turn simple literal macros with expansions <number>, -<number>, or (-<number>) into Swift read-only properties. Map integer literals to Swift 'Int' and float literals to Swift 'Double' for want of a better type to map them to--it would probably be better if we had a decl that behaved like Pascal 'const' and converted like a literal value. Codegen for the synthesized properties isn't wired up, so compiling code that tries to use macro values will currently die because of missing externals.
Swift SVN r3941
Only import visible categories as extensions. Don't import hidden ones
(whether from submodules or elsewhere), and most importantly don't use
the raw category chain.
Swift SVN r3792
This allows us to add additional module import paths besides those provided
in the sysroot. This is necessary for the demo (so we can import our custom
ScriptingBridge header file) and will probably be needed in some form in the
long run to support mixed Swift/Objective-C projects.
Swift SVN r3721
When we import an Objective-C protocol, we add the "Proto" suffix to
the name to avoid collisions when a class and protocol have the same
name. Of course, one's "Proto"-suffixed declarations will still
conflict, so this rule isn't great.
Swift SVN r3642
Swift's diagnostic system is built on the quaint notion that every
declaration known to the front end has a valid source location to
which diagnostics mentioning that declaration (say, in a "here is a
candidate" note) can point. However, with a real module system, the
source corresponding to a declaration in a module does not need to be
present, so we can't rely on source locations.
Instead of source locations, allow diagnostics to be anchored at a
declaration. If that declaration has source-location information, it
is used. Otherwise, we just drop source-location information for
now. In the future, we'll find a better way to render this information
so it feels natural for the programmer.
Swift SVN r3413
This commit covers only the AST-building side of indexed
subscripting, mapping objectAtIndexedSubscript: and
setObject:atIndexedSubscript: to Swift 'subscript' declarations. IR
generation and support for keyed subscripting to follow.
Swift SVN r3377
With this change, I'm able to import Cocoa (using my hacked OSX 10.9 SDK,
naturally) into Swift and poke at various classes and methods with
-parse. Runtime tests still fail, however.
Swift SVN r3274
This is mostly a hack to work around differences between how Swift and
Clang name lookup into modules works. However, it allows us to load
multiple Clang modules into Swift without causing spurious
ambiguities. The generation-based versioning isn't stricly necessary,
since module imports are resolved up front. However, we may eventually
want to speculatively load modules as part of name binding or type
checking, in which case we'd rather not have stale caches. And it
costs us very little.
Swift SVN r3269
Note that we probably also want to do this if we're in a type context
and we found non-type declarations, so that "stat" referenced in a
value context finds the function, but in a type context finds the
type.
Swift SVN r3222
