Autolinking was added to the frontend in 22912bc3b. It was disabled on
Linux in 198402dcf, and further constrained to be disabled on "linux-gnu"
in 83b4384fa. Since then, more flavors of Linux have become supported
by Swift: "linux-gnueabihf" in 4bf81e09d, and "freebsd" in f41b791d4.
Autolinking most likely does not work on any of these platforms, so
mark it as unsupported for now.
Other tests that only mark "linux-gnu" as unsupported do so for similar
reasons. Ensure unsupported tests for "linux-gnu" are also unsupported
on similar platforms.
Finishes up https://bugs.swift.org/browse/SR-280. At this point, nothing
should be passing O(N) arguments on the command line, where N is the
number of input source files, unless N is small.
(There are other inputs which are passed through to subtools, and these
are not put into filelists. That's fine.)
With this, we're out of the business of passing large numbers of input
files on the command line to the frontend, which means we no longer
overflow argv with a mere 1100 input files under whole-module optimization.
In order to make sure this doesn't happen again, I'd like to also get
this working for
- swiftmodule inputs to the merge-module build phase
- /output/ files for multithreading single-frontend builds (WMO)
- object file inputs to the linker on OS X (response files for binutils
ld have different quoting rules)
Part 3 of https://bugs.swift.org/browse/SR-280.
This commit removes the flag '-disable-func-sig-opts' from a bunch of tests and
fixes all of the affected tests. This flag was introduces when the
function-signature-opt optimization was introduced and we did not port the old
tests. Now the day has come to clean all of the old tests and delete the flag.
Public Clang calls itself "Clang"; Apple Clang calls itself "Apple LLVM".
The test doesn't actually care what the name is; it's just trying to make
sure that the importer is failing for the reason we expect, rather than
something unrelated.
rdar://problem/23506925
'Ss' appears in manglings tens of thousands of times in the standard library and is also incredibly frequent in other modules. This alone is enough to shrink the standard library by 59KB.
Swift SVN r32409
This should have no functionality change, but is supposed to keep us from
accidentally relying on the "full" Clang importer when in a backend job.
I tested it by archiving a little iOS app from a developer.
Unfortunately, part of the motivation here was that we'd get error messages when
we pass something Clang doesn't like, and that doesn't seem to be happening.
rdar://problem/21389553
Swift SVN r30407
- (depends|provides)-top-level for top-level names.
- (depends|provides)-nominal for access into nominal types.
- (depends|provides)-dynamic-lookup for @objc members available on AnyObject.
- depends-external for cross-module file-based dependencies.
No functionality change.
Swift SVN r30283
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
