This patch fixes a problem where a CompilerInvocation
with no arguments would set the LangaugeOpts etc. up for
the deprecated-integrated-repl, including setting the
module name etc. Now this only happens if you explicitly
invoke swift -frontend -repl.
Updated testcases that care, and added a new testcase to
ensure that an error is properly generated.
<rdar://problem/17918172>
Swift SVN r21537
This allows UnicodeScalars to be constructed from an integer, rather
then from a string. Not only this avoids an unnecessary memory
allocation (!) when creating a UnicodeScalar, this also allows the
compiler to statically check that the string contains a single scalar
value (in the same way the compiler checks that Character contains only
a single extended grapheme cluster).
rdar://17966622
Swift SVN r21198
Without this, clients that don't use a CompilerInstance (like LLDB) won't
have target configuration options available.
Also, move minimum OS checking into the driver. This makes sure the check
happens early (and only once), and in general fits the philosophy of
allowing the frontend to use configurations that might be banned for users.
<rdar://problem/17688913>
Swift SVN r20701
Most of the tests just got moved to swiftc, but some of them were
duplicated to apply to both swiftc and swift. A handful still use the
existing 'swift' because they are for the existing '-i' syntax.
Note: this means config.swift_driver now uses the staging symlink
'swifti'. The only thing preventing us from dropping the 'i' and getting
rid of the old interface is that Xcode hasn't moved to swiftc yet
<rdar://problem/17769327>.
Swift SVN r20467
We were already effectively doing this everywhere /except/ when building
the standard library (which used -O2), so just use the model we want going
forward.
Swift SVN r20455
This catches code that tries to use the llvm::cl interface. Those options
are used by -Xllvm's processing and must not be interfered with.
Swift SVN r20146
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
assert() and fatalError()
These functions are meant to be used in user code. They are enabled in debug
mode and disabled in release or fast mode.
_precondition() and _preconditionFailure()
These functions are meant to be used in library code to check preconditions at
the api boundry. They are enabled in debug mode (with a verbose message) and
release mode (trap). In fast mode they are disabled.
_debugPrecondition() and _debugPreconditionFailure()
These functions are meant to be used in library code to check preconditions that
are not neccesarily comprehensive for safety (UnsafePointer can be null or an
invalid pointer but we can't check both). They are enabled only in debug mode.
_sanityCheck() and _fatalError()
These are meant to be used for internal consistency checks. They are only
enabled when the library is build with -DSWIFT_STDLIB_INTERNAL_CHECKS=ON.
I modified the code in the standard library to the best of my judgement.
rdar://16477198
Swift SVN r18212
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
_precondition_safety_check
The check is enabled in debug and release mode. In debug mode it prints a
useful error message. In release mode it traps. In fast mode this is a noop.
_partial_safety_check
The check is only enabled in debug mode (-Onone).
_internal_library_check
The check is only enabled when the standard library is compiled with
"SWIFT_STDLIB_INTERNAL_CHECKS" set to on/yes. It is a noop if the above option
is not specified.
rdar://16477198
Swift SVN r17789
Moved the check for unknown arguments ahead of any other attempts to handle arguments.
Added test/Frontend/unknown-arguments.swift, which tests the unknown argument handling of "swift_driver -frontend".
Swift SVN r11157
