The rule changes are as follows:
* All functions (introduced with the 'func' keyword) have argument
labels for arguments beyond the first, by default. Methods are no
longer special in this regard.
* The presence of a default argument no longer implies an argument
label.
The actual changes to the parser and printer are fairly simple; the
rest of the noise is updating the standard library, overlays, tests,
etc.
With the standard library, this change is intended to be API neutral:
I've added/removed #'s and _'s as appropriate to keep the user
interface the same. If we want to separately consider using argument
labels for more free functions now that the defaults in the language
have shifted, we can tackle that separately.
Fixes rdar://problem/17218256.
Swift SVN r27704
Move helper function EmbedBitcode() from frontend_main.cpp to IRGen.cpp so we
can call it from performIRGeneration when the input file is Swift.
Add testing case to make sure that -embed-bitcode-marker option adds an
empty LLVM bitcode section.
rdar://19048891
Swift SVN r25577
With -embed-bitcode, save a copy of the llvm IR as data in the __LLVM,__bitcode
section and save the command-line options in the __LLVM,__cmdline section.
rdar://19048891
Swift SVN r25560
For now, just emit a warning. Later on we can actually get this right for
multiple files.
This is important for people manually trying to reduce run lines that come
from Xcode.
rdar://problem/19786899
Swift SVN r25388
This is required to correctly use the mock SDK when the SDK overlay is
built and tested separately. (Otherwise, the mock SDK might not get
used, because the overlay SDK options would expand from the
%-substitution, appear first on the command line, and shadow the mock
SDK in the search path).
Swift SVN r25185
Yes, they may not be correct, but the stale ones that were there before
won't be correct either (if they were there at all). This should make both
Xcode and the Swift driver less likely to have issues when there's an error
in a newly added file.
Goes with rdar://problem/19640006
Swift SVN r24824
Most tests were using %swift or similar substitutions, which did not
include the target triple and SDK. The driver was defaulting to the
host OS. Thus, we could not run the tests when the standard library was
not built for OS X.
Swift SVN r24504
These are the same dependencies collected for .d files, including
headers and imported swiftmodules. These can also cause a file to be out
of date.
Part of rdar://problem/19270920
Swift SVN r24334
The SwiftShims module is a private dependency of the standard library,
so it shouldn't really show up in the generated .d file. However, it's
doing any harm by being there in +Asserts builds, so for now just don't
check. See rdar://problem/19318312.
Swift SVN r24096
Because the bots build a release+asserts compiler and an unchecked stdlib, this
test is not currently applicable. The checked version of this test was disabled
but this test should've been disabled as well.
Original commit message r23074:
Fix the bots by requiring two options on this test that never can co-exist as true.
This is to work around a bug on the unchecked optimized stdlib builder which due
to a problem in the cmake build chain runs the checks enabled version of this
test. This commit makes sure that the test will not run until this is resolved.
Swift SVN r23624
This is to work around a bug on the unchecked optimized stdlib builder which due
to a problem in the cmake build chain runs the checks enabled version of this
test. This commit makes sure that the test will not run until this is resolved.
Swift SVN r23074
This is needed for tests which define internal functions which should not be eliminated.
So far this was not needed because of a hack which prevented whole-module-optimizations for tests.
Swift SVN r22658
This is most important for -Xcc options, which shouldn't be dependent on
the underlying Clang version, but it also affects things like target features
that Clang knows how to compute correctly and Swift, well, doesn't.
rdar://problem/17687572
Swift SVN r22448
This prevented dead function removal of inlined dead functions. Beside the stdlib it's mostly
an issue of SIL size (and therefore compiletime), because llvm did remove such functions anyway.
Swift SVN r22301
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
