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
Parse-only is a hot path; keep the semantics for it separate from normal parsing, otherwise it is very
easy to introduce something expensive without checking for Invocation.getParseOnly().
Also cleans up a bit CompilerInstance::performParse() as well.
Swift SVN r17596
This improves the -import-objc-header option to read decls from the header
as well. Any declaration that is not from a module will be considered to be
part of the "header module". Conversely, forward-declarations appearing in
the header will be resolved by looking through all modules responsible for
importing a header.
More of <rdar://problem/16702101>
Swift SVN r17492
THIS IS NOT READY FOR USE YET.
The new plan for mixed-source non-framework targets is that the Swift
compiler will import an Objective-C header directly, and treat the decls
and imports in that header as explicitly visible to the entire target.
This means users don't have to modularize their headers before bringing
them into Swift.
This commit adds the option and introduces the "imported headers" module
as an implicit import for the source files being compiled. It also directs
the Clang importer to process the given header (using #import, so that it
won't somehow get included twice) and watches for any module imports that
occur as a result of reading that header.
Still to come: import of decls within the header (not within any module),
and proper serialization of cross-references to the header and its imports.
Part of <rdar://problem/16702101>
Swift SVN r17218
This option implicitly imports the Clang module with the same name as the
module being built into every source file in the module being built.
This will be used for mixed-source framework targets to give Swift code the
same implicit visibility for Objective-C decls in the same module that it
already has for other Swift decls.
<rdar://problem/16701230>
Swift SVN r17053
Also, create the Clang module loader directly rather than indirecting through
a "get constructor" function. It's no longer a valid configuration to not
have a Clang importer.
Swift SVN r16862
The hardcoding of CPU settings in lib/Driver/Tools.cpp isn't at all ideal,
but it will let us limp along for now.
<rdar://problem/16641385>
Swift SVN r16861
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
marked as erroneous
This is important so that other parts of the compiler (e.g., AST verifier) are
less strict about AST invariants.
Alternatively, we could make sure to emit a diagnostic in the parser when we
consume the code completion token, but chasing every place where we do it now
(and remembering to do this in future) does not scale well.
Fixes the crash in rdar://problem/16100914
Swift SVN r14865
"Playground Transform." This is an
instrumentation pass that adds calls to a
function called playground_log at locations of
interest. Roughly speaking, these locations are
- Initialization of variables
- Modification of variables
- Expressions returning values
- Application of mutating methods on objects
The playground transform currently only finds
modifications of variables, but the intent is to
make all of these cases work.
It is enabled by a frontend option, and can
also be invoked by calling
swift::performPlaygroundTransform(SF)
which is the way LLDB, its main client, will
use it.
The frontend option is intended for testing,
and indeed I will add tests for this
transformation in the coming week as I bring
more functionality online.
Swift SVN r14801
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
to be careful when iterating over the vector of all files and type checknig
them.
This is related to rdar://16153700, but it looks like that it does not yet
completely fix it.
Swift SVN r14589
Also, add more tests for the "os" and "arch" target configurations, to exercise likely
build configurations for iOS and the iOS simulator.
Swift SVN r14307
- Respond to Doug's code review feedback
- Stop hacking around with scopes and use "emplace" to work around RAII in the inactive config case
- Limit use of StringRef on the front-end, in favor of std::string
- Use ArrayRef rather than SmallVector within IfConfigDecl
- Reorder new property declarations on BraceStmt to prevent unnecessary alignment issues
- Update ParseBraceItems to better capture top-level declarations, rather than using token lookahead
Swift SVN r14306
These changes add support for build and target configurations in the compiler.
Build and target configurations, combined with the use of #if/#else/#endif allow
for conditional compilation within declaration and statement contexts.
Build configurations can be passed into the compiler via the new '-D' flag, or
set within the LangOptions class. Target configurations are implicit, and
currently only "os" and "arch" are supported.
Swift SVN r14305
This is mostly useful for the standard library, whose name is going to
change to "Swift" soon. (See <rdar://problem/15972383>.) But it's good DRY.
Swift SVN r13758
Also, disallow creating Modules and FileUnits on the stack. They must always
live as long as the ASTContext.
<rdar://problem/15596964>
Swift SVN r13671
Because this is useful in testing, I've left in a frontend option
-enable-source-import for both swift and swift-ide-test that sidesteps the
module restriction. Right now, though, this is the right thing to avoid
users running into strange issues when they import another file within
their module and Swift treats it as a separate module.
<rdar://problem/15937521>
Swift SVN r13248
This has the potential to significantly reduce compile times in primary file
mode: for example, compiling Song.swift from the Name That Tune example as the
primary file previously took ~2.0s with a release build on my machine; with this
change, it now only takes ~0.8s. (The old compile time was presumably dominated
the time it takes to type-check AppDelegate.swift, which is a larger file.)
Swift SVN r13140
This adds some ugliness in the current swift binary because we weren't
bothering to set a requested action before, but it keeps things simpler
elsewhere. (Thanks, Connor.)
Swift SVN r13067
This necessitated adding a new function to validate a serialized AST, so
that we can get the same information that used to be extracted from the
section header.
For now, we'll continue accepting the wrapped ASTs as well, since we
haven't changed the existing debug info generator.
Swift SVN r12922
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
Hardcoding a path to a particular SDK is definitely the wrong thing to do.
Let's see how far we can get without setting a default SDK.
See discussion in <rdar://problem/14395800>
Swift SVN r12414
During CompilerInstance::performParse(), set CompilerInstance::PrimarySourceFile if we create a SourceFile from a buffer whose ID matches the PrimaryBufferID.
This allows clients of CompilerInstance to get a SourceFile for the user-specified primary input.
Swift SVN r12156
This matches how we will handle primary inputs.
This also fixes an issue where a file named main.swift may not be chosen as the main file if there were multiple inputs and it was replaced by an input buffer.
Swift SVN r12154
