The driver infers the filename from the module file by replacing the extension,
and passes the explicit path to the swiftdoc file to the frontend. But there
is no option in the driver to control emission of swiftdoc (it is always
emitted, and name is always inferred from the swiftmodule name).
The swiftdoc file consists of a single table that maps USRs to {brief comment,
raw comment}. In order to look up a comment for decl we generate the USR
first. We hope that the performance hit will not be that bad, because most
declarations come from Clang. The advantage of this design is that the
swiftdoc file is not locked to the swiftmodule file, and can be updated,
replaced, and even localized.
Swift SVN r14914
Make the name lookup interfaces all take DeclNames instead of identifiers, and update the lookup caches of the various file units to index their members by both compound name and simple name. Serialized modules are keyed by identifiers, so as a transitional hack, do simple name lookup then filter the results by compound name.
Swift SVN r14768
Sema was creating DerivedFileUnit on the fly, while something else is iterating
over FileUnits in the module. The fix is to create DerivedFileUnit in advance.
This change immediately uncovered a lot of code that assumed that the module
consists of a single FileUnit at certain conditions. This patch also fixes
that code (SourceKit patch is separate, not sending it).
The test change is because now operator == on NSObjects is correctly recognised
as coming from a system module.
rdar://16153700, rdar://16227621, possibly rdar://16049613
Swift SVN r14692
Teach name lookup to find complete object initializers in its
superclass when the current class overrides all of the subobject
initializers of its direct superclass.
Clean up the implicit declaration of constructors, so we don't rely on
callers in the type checker doing the right thing.
When we refer to a constructor within the type checker, always use the
type through which the constructor was found as the result of
construction, so that we can type-check uses of inherited complete
object initializers. Fixed a problem with the creation of
OpenExistentialExprs when the base object is a metatype.
The changes to the code completion tests are an improvement: we're
generating ExprSpecific completion results when referring to the
superclass initializer with the same signature as the initializer
we're in after "super.".
Swift SVN r14551
If an enum has no cases with payloads, make it implicitly Equatable and Hashable, and derive default implementations of '==' and 'hashValue'. Insert the derived '==' into module context wrapped in a new DerivedFileUnit kind, and arrange for it to be codegenned with the deriving EnumDecl by adding a 'DerivedOperatorDecls' array to NominalTypeDecls that gets visited at SILGen time.
Swift SVN r14471
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 re-applies r13401, reverted in r13404. This wasn't actually causing
problems, but got pulled along with r13400 (reverted in r13405).
Swift SVN r13452
Also, remove the mode that left the current module out of the callback.
That's easy enough to check for.
No functionality change yet, but groundwork for the next commit (as well
as some possible uses in LLDB).
Swift SVN r12616
location of variables at SIL generation time.
This patch introduces a SILDebuggerClient that
knows how to resolve the locations of variables
that are generated by the debugger. These
variables have a flag on them that only LLDB
sets.
Swift SVN r11230
Check for a REPL SourceFileKind along with Main before going the lazy initialization path. Also put response variables in the REPL SourceFile decl context so they are recognized as REPL variables and not lazily initialized. Handle PatternBindingDecls that appear under a script-mode SourceFile decl context but not a TopLevelCodeDecl context.
Swift SVN r11133
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
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
Qualified lookup depends not only on the current module but actually the
current file, since imports are file-scoped by default. Currently this only
affects lookup into other modules (e.g. "Foundation.NSString"), but this
could also be used for extension filtering.
This breaks one name resolution test, but the refactoring in the next
commit changes everything anyway and will restore the test.
Swift SVN r10831
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
Previously we would cache the results of operator lookup whether or not the
operator we found came from an imported module. Since different source files
can have different imports, it's not correct to automatically share operators
from imported modules with all files in the translation unit.
This still isn't fully correct; the current logic prefers operators from
local imports over operators implicitly available from other source files.
Swift SVN r9683
Anywhere that assumes a single input file per TU now has to do so explicitly.
Parsing still puts all files in a single SourceFile instance; that's next on
the list.
There are a lot of issues still to go, but the design is now in place.
Swift SVN r9669
The operator lookup cache already lived in SourceFile, but we need to be
able to look up operators on a per-SourceFile basis. Different files can
have different imports. The interface previously distinguished between
"no operator found" and "error", but none of the call sites were making
use of this distinction, and indeed some were misusing the return value
(Optional<SomeOperatorDecl *>). Now the lookup functions just return
operator decl pointers, which may be null.
Swift SVN r9668
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
Being able to pass -l to the driver isn't so interesting, and it's an
extra field that lives on TranslationUnit for no reason. Just remove it.
This doesn't interfere with autolinking, i.e. inferring -l flags based on
imported modules.
Swift SVN r9241
LLVM's SourceMgr uses 'int' for buffer IDs, but -1 is a special placeholder
value that means "no such buffer". Swift's SourceManager then makes a
distinction between 'unsigned' and 'int' -- an unsigned buffer ID always
refers to an actual buffer, while an int ID may be -1. Respect this in
SourceFile, which uses Optional to represent a "potential" buffer.
Swift SVN r9239
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
Right now this is just an extra layer of indirection for the decls,
operators, and imports in a TU, but it's the first step towards compiling
multiple source files at once without pretending they're all in a single
file. This is important for the "implicit visibility" feature, where
declarations from other source files in the same module are accessible
from the file currently being compiled.
Swift SVN r9072
UnqualifiedLookup to ask an external source for
names. There are two phases to this external lookup:
- Before consulting globals in other modules,
UnqualifiedLookup calls lookupOverrides() to see
if there are any results that should override the
results from modules. (N.b.: these should not be
able to override names that are locally defined.)
- After consulting globals in other modules,
UnqualifiedLookup as a last resort calls
lookupFallbacks() to see if there's anything out
there at all that could serve that name. This may
be more computationally expensive.
These hooks are used by LLDB's expression parser to
resolve names for persistent variables (akin to the
existing $0, $1, ... variables) and variables local
to the current frame.
Swift SVN r9014
