The name used for name lookup of subscript operators is "__subscript",
but when looking into an Objective-C module we instead need to look
for methods with the subscripting selectors, e.g.,
objectAtIndexedSubscript:/objectForKeyedSubscript:. Do so, and make
sure that deserializing the method first still creates the subscript
declaration.
Fixes the majority of <rdar://problem/14656624>. We can subscript 'id' now.
Swift SVN r8700
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
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
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
We can get to these transitively; we should only record what the TU
actually claims to reference.
It turns out that we were still relying on this to force the load of
adapter modules for Clang modules. For now, we just force that up front,
even though currently that also forces the creation of ClangModule
wrappers for all transitive includes.
No intended visible functionality change.
Swift SVN r7012
modules, put the imported decl into the ClangModule where the canonical
decl is.
This is not a complete fix, the function should be visible from all modules
that declare it. See rdar://14665250
Swift SVN r6956
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 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
