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
Once we have multiple SourceFiles in a TranslationUnit, it no longer makes
sense to say "only SILGen decls starting from element N" without specifying
which source file you mean.
Also, clarify ownership by having performSILGeneration return a unique_ptr
instead of just a bare pointer.
Swift SVN r9112
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
This reverts r8624 and compensates by passing the TU to the SILModule printer when needed.
This addresses concerns that Jordan and Sean had raised.
Swift SVN r8678
...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
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
Also have CompilerInvocation store the RuntimeIncludePath and calculate it via the MainExecutablePath
instead of the other way around (store MainExecutablePath and calculate RuntimeIncludePath when requested)
Swift SVN r7170
Also centralizes the knowledge about whether the hashbang is allowed in the
SourceManager. This fixes a bug in tokenize() because previously it just had
to guess.
Swift SVN r6822
around everywhere
Fixes:
rdar://14585108 Code completion does not work at the beginning of the file
rdar://14592634 Code completion returns zero results at EOF in a function
without a closing brace
Swift SVN r6820
This closes out <rdar://problem/14513108> -- sil-opt no longer depends on
ClangImporter or any Clang libraries. In theory, however, forcing a load
of a libSwiftClangImporter.dylib would allow sil-opt to process SIL files
containing Clang imports.
Swift SVN r6700
-Introduce PersistentParserState to represent state persistent among multiple parsing passes.
The advantage is that PersistentParserState is independent of a particular Parser or Lexer object.
-Use PersistentParserState to keep information about delayed function body parsing and eliminate parser-specific
state from the AST (ParserTokenRange).
-Introduce DelayedParsingCallbacks to abstract out of the parser the logic about which functions should be delayed
or skipped.
Many thanks to Dmitri for his valuable feedback!
Swift SVN r6580
This mainly removes the extraneous DiagnosticEngine and SourceMgr from CompilerInvocation.
Instances of these can be found via the CompilerInstance object.
Swift SVN r6496
Add a little dance in the setup of the Clang importer. Now, clients that don't care
about the clang importer don't have to link it in, just don't call setSDKPath()
Swift SVN r6462
* Added a mode in swift-ide-test to test code completion. Unlike c-index-test,
the code completion token in tests is a real token -- we don't need to
count lines and columns anymore.
* Added support in lexer to produce a code completion token.
* Added a parser interface to code completion. It is passed down from the
libFrontend to the parser, but its functions are not called yet.
* Added a sketch of the interface of code completion consumer and code
completion results.
Note: all this is not doing anything useful yet.
Swift SVN r6128
