This allows swiftFrontend to drop its dependency on swiftDriver, and could
someday allow us to move the integrated frontend's option parsing out of
swiftFrontend (which would allow other tools which use swiftFrontend to
exclude the option table entirely).
Swift SVN r19824
attribute is a "modifier" of a decl, not an "attribute" and thus shouldn't
be spelt with an @ sign. Teach the parser to parse "@foo" but reject it with
a nice diagnostic and a fixit if "foo" is a decl modifier.
Move 'dynamic' over to this (since it simplifies some code), and switch the
@optional and @required attributes to be declmodifiers (eliminating their @'s).
Swift SVN r19787
The driver option -i now requires an input file as argument, and any
options after the input file will be treated as arguments to the
interpretted file.
This also renames the frontend option to -interpret, since it is parsed
as a flag, unlike -i. We could support -interpret in the driver if we
wanted, which would allow us to use --, but wouldn't work with shebang
scripts. For now, it's frontend-only.
Swift SVN r19718
This only works when swift is packaged with Xcode or installed as a command
line tool, but those are the important cases.
<rdar://problem/14395800>, again.
Swift SVN r18757
Previously, the frontend detected that its output was being piped into the
driver and buffered, and decided that that wasn't a color-friendly output
stream. Now, the driver passes -color-diagnostics to the frontend to force
color output if the driver itself is in a color-output context.
<rdar://problem/16697713>
Swift SVN r18506
As with ARM64, we need to be specific about the -target-abi or we end up
defaulting to something that is not appropriate for our platforms.
Fixes <rdar://problem/16821282>.
Swift SVN r18163
When a module built with -autolink-force-load is imported, add a reference
to a special symbol in the corresponding library so that ld is forced to
link it.
This means the library will be linked into the final binary even if no other
symbols are used (which happens for some of our overlays that just add
category methods to Objective-C classes).
Second part of <rdar://problem/16829587>
Swift SVN r17751
This option puts a special symbol into the generated object files that other
object files can reference to force the library to be loaded.
The next commit will modify the way we serialize autolinking information so
that importers of this module will always emit a reference to this symbol.
This means the library will be linked into the final binary even if no other
symbols are used (which happens for some of our overlays that just add
category methods to Objective-C classes).
Part of <rdar://problem/16829587>
Swift SVN r17750
This doesn't handle cross-references to decls /loaded/ from the header
just yet, so all that's testable right now is whether the header's imports
are visible from the secondary target (after being imported in response
to loading the serialized module).
More of <rdar://problem/16702101>
Swift SVN r17638
When importing an Objective-C init method or factory method into an
initializer, if the first camelCase word of the first argument name
starts with "with", drop the "with". This means that
-initWithRed:green:blue:alpha:
will get imported into Swift as
init(red:green:blue:alpha:)
as will
+colorWithRed:green:blue:alpha:
This is <rdar://problem/16795899>, hidden behind the
-implicit-objc-with flag.
Swift SVN r17271
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
Another baby step toward <rdar://problem/14462349>, made even more
tepid by the fact that I've quarantined this behind a new flag,
-strict-keyword-arguments. Enforcing this breaks a lot of code, so I'd
like to bring up the new model on the side (with good diagnostics that
include Fix-Its) before trolling through the entire standard library
and testsuite to fix violations of these new rules.
Swift SVN r17143
Since LLDB is taking over as the REPL for Swift, we eventually want "swift"
and "swift -repl" to invoke "lldb --repl" rather than the frontend. However,
we only want to do this if the LLDB that's present is related to the Swift
that's present -- we don't want to invoke some random LLDB on the system
or in some other Xcode installation. Therefore, Swift searches for LLDB--
first next to the driver, then in the usr/bin/ outside of a toolchain--
before choosing to use it.
If the user just passes -repl and an LLDB is not found relative to the
driver, the existing "integrated" REPL will be launched instead.*
If the user passes -lldb-repl and an LLDB is not found relative to the
driver, one from the user's PATH will be chosen (like the linker).
The user can also pass -integrated-repl to get the existing behavior.
"swift -frontend -repl" always uses the integrated REPL.
* Since LLDB's not quite ready to be the REPL yet, "swift -repl" still
invokes the integrated REPL. "swift -repl -experimental-prefer-lldb" tests
the new behavior; this option will become the default (and the flag removed)
in <rdar://problem/16776719>.
<rdar://problem/16776705>
Swift SVN r17134
* Temporarily turn on -link-objc-runtime by default. This will be
removed again in rdar://16753644.
* Symlink XcodeDefault.xctoolchain's copies of arclite into the Swift build's
resource directory so tests can see it.
* Enable the KVO test.
Swift SVN r17132
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
which provides the Neon feature. Do all the necessary
plumbing to get this from the driver to the backend.
Also, support -arch arm64, and diagnose bad -arch values
instead of silently ignoring them. It's not clear to me
that we really want to support -arch as an alternative
to -target, but unless we rip it out or establish some
sort of real policy about it, it really ought to do
something approximating the right thing.
It would be nice if we could abstract enough of clang's
driver that we could re-use some of its basic logic about
tool chains and targets instaed of iteratively
rediscovering everything it does that's actually
critically important.
Swift SVN r16447
Centralize the logic for figuring out what name to use for a class or
protocol in the Objective-C runtime. When the flag is enabled (it's
still disabled by default), use mangled names for all Swift-defined
classes, including those that are @objc. Note that the naming is
determined in the AST, because we're also going to use this logic when
printing an Objective-C header for Clang's consumption. The mangled
names will always start with _Tt, so they're easy to recognize and
demangle in various tools or, eventually, in the Objective-C runtime.
The new test (test/IRGen/objc_mangling.sil) is the only test of this
behavior at the moment. The other test changes are due to the
centralized logic tweaking the names of internal constants (_DATA_*,
_CATEGORY_*, etc.).
This is the majority of <rdar://problem/15506580>.
Swift SVN r15588
The frontend/driver flag is "-application-extension'. This
activates a language option which will be used for more restrictive
availability checking.
Operationally, this also passes...
- "-fapplication-extension" to the clang importer
- "-application_extension" to ld
Swift SVN r15543
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
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
Previously we only passed -module-cache-path to the compilation jobs, which
meant the module merging jobs would default to using the system module cache
(which means double the Clang work if the module cache had been set, and
strange errors during development when Clang's serialized format changes).
We hadn't been passing -F to either job because we hadn't been worrying
about non-system frameworks, but that's likely to change soon.
I also consolidated the forwarding of -Xfrontend args in this commit.
I've convinced myself that this will pretty much always be necessary for the
merge-module step, and that we should have something else if we really
need to differentiate the two.
<rdar://problem/16113207>
Swift SVN r14114
This is equivalent to Clang's -fresource-dir; it provides the location of
compiler modules and libraries.
No end-user-visible changes, but the iOS build will no longer have to use
-I to build and test its own standard libraries.
Swift SVN r13888
