This is enabled by default because SILGen can crash when @objc is used without importing Foundation, but
it gets disabled when compiling the Swift stdlib.
Addresses rdar://17931250.
Related test case on the SourceKit side.
Swift SVN r21319
The LLDB REPL doesn't guarantee any particular module name, and in particular
it currently uses multiple modules to handle redefinitions.
<rdar://problem/17918172>
Swift SVN r21303
While we work out the remaining performance improvements in the type checker, we can improve the user experience for some "runaway solver" bugs by setting a limit on the amount of temporary memory allocated for type variables when solving over a single expression.
Exponential behavior usually manifests itself while recursively attempting bindings over opened type variables in an expression. Each one of these bindings may result in one or more fresh type variables being created. On average, memory consumption by type variables is fairly light, but in some exponential cases it can quickly grow to many hundreds of megabytes or even gigabytes. (This memory is managed by a distinct arena in the AST context, so it's easy to track.) This problem is the source of many of the "freezing" compiler and SourceKit bugs we've been seeing.
These changes set a limit on the amount of memory that can be allocated for type variables while solving for a single expression. If the memory threshold is exceeded, we can surface a type error and suggest that the user decompose the expression into distinct, less-complex sub-expressions.
I've set the current threshold to 15MB which, experimentally, avoids false positives but doesn't let things carry on so long that the user feels compelled to kill the process before they can see an error message. (As a point of comparison, the largest allocation of type variable data while solving for a single expression in the standard library is 592,472 bytes.) I've also added a new hidden front-end flag, "solver-memory-threshold", that will allow users to set their own limit, in bytes.
Swift SVN r20986
This flag is now obsoleted by the interactive driver and simply
complicates understanding the command-line parsing. Making it an error
to force users to move also allows us to reuse the flag in the future if
we like.
Swift SVN r20641
This makes the command line interface to 'swift' the same as what was
previously in 'swifti', and removes the staging symlink.
For posterity, the command line behaviour for 'swift' is now:
* `swift` -> start the repl
* `swift script.swift` -> run script.swift (the old -i mode)
* Any arguments after the input file are forwarded to the script as
Process.arguments
* A shebang line is something like #!/usr/bin/xcrun swift
The batch compiler 'swiftc' behaves much like the old 'swift'
executable, but without the interactive bits now in 'swifti'.
<rdar://problem/17710788>
Swift SVN r20540
This matches Clang's behavior, though this implementation does not check
that it's actually on a platform that uses dsymutil.
<rdar://problem/16012971>
Swift SVN r20529
Rather than embed AST info directly in binaries, we now include a special
symbol table entry that points to the serialized AST as a separate file.
This requires a very recent version of ld.
We still want to support the __SWIFT,__ast section in a binary because
that's how it's modeled in dSYM, so manually test both modes in
ASTSection_linker.swift.
Part of <rdar://problem/15796201>.
Swift SVN r20421
For now, keep 'swift' the same and put all the interactive driver
changes under 'swifti'. When these are in good shape, I will remove
swifti and make 'swift' the interactive driver as discussed.
Swift SVN r20359
Added support in Driver which allows -force-single-frontend-invocation and
-emit-objc-header[-path] to be used together in a single invocation.
Added support in tools::Swift to pass -emit-objc-header-path if an Objective-C
header was requested; this is only valid in OutputInfo::Mode::SingleCompile
mode, and an assertion enforces this.
Added a test which ensures that the same header is emitted in with
-force-single-frontend-invocation and without it.
Swift SVN r20185
Really we need to just bring in Clang's logic for this, but this should
at least bring SSE back for the 32-bit simulator.
<rdar://problem/17283844>
Swift SVN r19834
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
