This is the first testcase and includes the test
harness which will work for other testcases as
well.
Also includes a fix to make sure that we only
instrument once per main source file, and not
once per parse as we were doing before.
Swift SVN r20456
Run whole-module checks at the end of perform Sema, specifically
TryAddFinal. After everything has been type checked, accessibility has
been provided, and we have had a chance to see any potential
overrides, we try to add the final attribute to class members.
This ends up de-virtualizing many functions, or rather they avoid the
vtable altogether. Thus, there are many test file changes. New test
file add_final.swift. Other tests updated to either reflect the
non-virtual call, or to have public added to them.
Swift SVN r20338
We do this so that the swiftmodule file contains all info necessary to
reconstruct the AST for debugging purposes. If the swiftmodule file is copied
into a dSYM bundle, it can (in theory) be used to debug a built app months
later. The header is processed with -frewrite-includes so that it includes
any non-modular content; the user will not have to recreate their project
structure and header maps to reload the AST.
There is some extra complexity here: a target with a bridging header
(such as a unit test target) may depend on another target with a bridging
header (such as an app target). This is a rare case, but one we'd like to
still keep working. However, if both bridging headers import some common.h,
we have a problem, because -frewrite-includes will lose the once-ness
of #import. Therefore, we /also/ store the path, size, and mtime of a
bridging header in the swiftmodule, and prefer to use a regular parse from
the original file if it can be located and hasn't been changed.
<rdar://problem/17688408>
Swift SVN r20128
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 is better than requiring people to go through Ctx.getModule() using
Ctx.StdlibModuleName. There aren't that many cases of this, but they
shouldn't be using a completely different API.
The default behavior remains the same: if the standard library has not been
loaded, null will be returned.
Refinement of r18796, which modified the behavior of SourceFiles to assume
that the standard library had already been loaded.
Swift SVN r18813
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
