LLVM's system_error.h has been changed to forward to the standard
version of the same. Update usage for the minor API changes that this
entails.
Based in part on a patch by Justin Bogner.
Swift SVN r18832
This doesn't really affect anyone in real life, but it will catch cases
where someone's trying to compile for iOS without the iOS stdlib around.
Swift SVN r18796
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
Also, disallow creating Modules and FileUnits on the stack. They must always
live as long as the ASTContext.
<rdar://problem/15596964>
Swift SVN r13671
Also, don't allow file-relative imports (i.e. don't consider a /source file's/
location as an include path). Both of these should be requested by the user,
at least at this point.
Swift SVN r13249
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
Thanks to the way we've set up our diagnostics engine, there's not actually
a reason for /everything/ to get rebuilt when /one/ diagnostic changes.
I've split them up into five categories for now: Parse, Sema, SIL, IRGen,
and Frontend, plus a set of "Common" diagnostics that are used in multiple
areas of the compiler. We can massage this later.
No functionality change, but should speed up compile times!
Swift SVN r12438
Also updated findModule() in SourceLoader.cpp and SerializedModuleLoader.cpp to get the ImportSearchPaths from the ASTContext’s SearchPathOpts, instead of directly from the ASTContext.
Swift SVN r11214
Added a new SearchPathOptions class to swiftAST, which will contain options like import search paths and the SDK path.
Moved the RuntimeIncludePath from CompilerInvocation into SearchPathOptions. For now, at least, the RuntimeIncludePath is handled separately from other ImportSearchPaths, since we can’t yet guarantee that RuntimeIncludePath is set up before we parse the ImportSearchPaths.
Added a SearchPathOptions member to ASTContext.
Updated findModule() in SourceLoader.cpp and SerializedModuleLoader.cpp to check RuntimeIncludePath after everything else if no module was found. (This matches existing behavior, which had RuntimeIncludedPath at the end of ImportSearchPaths.)
Swift SVN r11213
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
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
Also remove the SourceLoc parameter from addNewSourceBuffer(). In llvm::SourceMgr
it is used to indicate textual inclusion, which we don't have in swift.
Swift SVN r10014
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
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
Instead, pass a LazyResolver down through name lookup, and type-check
things on demand. Most of the churn here is simply passing that extra
LazyResolver parameter through.
This doesn't actually work yet; the later commits will fix this.
Swift SVN r8643
...unless the functions are declared [transparent], or if we're in an
immediate mode (in which case we won't get a separate chance to link
against the imported TUs).
This is an optimization that will matter more when we start dealing with
Xcode projects with many cross-file dependencies, especially if we have
some kind of implicit import of the other source files in the project.
In the future, we may want to parse more function bodies for the purpose
of inlining, not just the transparent ones, but we weren't taking
advantage of that now, so it's not a regression. (We're still not taking
advantage of it even for [transparent] functions.)
Swift SVN r7698
Every valid source location corresponds to a source buffer. There should be no
cases where we create a source location for a random string. Thus,
findBufferContainingLoc() always succeeds.
Swift SVN r7120
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 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
