libswiftStdlibStubs.a is meant to be an intermediate built product
that's pulled into libswiftCore.a, not its own thing. Add a post-build
step for libswiftCore.a to pull all the object files into it from
libswiftStdlibStubs.a.
(Also, be careful only to do this for private link libraries that are
actually targets.)
<rdar://problem/23621157>
libswiftStdlibStubs.a is meant to be an intermediate built product
that's pulled into libswiftCore.a, not its own thing. Add a post-build
step for libswiftCore.a to pull all the object files into it from
libswiftStdlibStubs.a.
<rdar://problem/23621157>
When we're building the compiler, we already depend on the "swift" target.
When we're /not/ building the compiler, it had better already be there.
Squelches a CMake warning.
This was defaulting to the build directory, which isn't helpful
post-install. Set Swift libraries to look in the same directory
(ORIGIN) or /usr/lib/swift/linux.
rdar://problem/22766758
This skips the Swift standard library due to the linker script incompatibility
issue.
As before for other related projects, the build-script-impl option
'--use-gold-linker' triggers usage of this.
Swift SVN r32706
When building overlay separately, look for dylibs in the overlay
build directory first, and only then fall back to the compiler resource
directory.
If the overlay changes the ABI, we shouldn't even try the dylibs in the
compiler resource directory, that is certain to fail the build or
result in miscompiles.
rdar://22866170
Swift SVN r32382
A couple of small tweaks to _compiler_version based on review comments:
- Fix &&/|| rejection to work with _compiler_version on either side of the
expression. Also add some test cases around this.
- Use clang/LLVM facilities for isdigit and atoi.
- Assert if parsing an invalid version string and there is no diagnostic
engine.
- Clean up some crumbs in the CMake configs.
rdar://problem/22730282
Swift SVN r32212
This configuration clause will suppress lex diagnostics and skip parsing
altogether if the code under the clause isn't active - the compiler must
have a repository version greater than or equal to the version given to
_compiler_version.
This option is only meant to be used sparingly and not to track the
Swift *language* version.
Example, if using a compiler versioned 700.0.28:
#if _compiler_version("700.0.23")
print("This code will compile for versions 700.0.23 and later.")
#else
This + code + will + not + be + parsed
#endif
Included are new diagnostics for checking that the version is formatted
correctly and isn't empty.
New tests:
- Compiler version comparison unit tests
- Build configuration diagnostics
- Skipping parsing of code under inactive clauses
rdar://problem/22730282
Swift SVN r32195
This reverts commit r31313.
This change caused an unacceptable dylib size increase:
- watchOS core dylib size increased from 13 Mb to 25 Mb,
- iOS dylib size increased 40 Mb to 76 Mb.
The size change is due to change of the bitcode section size. It can be
attributed to:
- actual symbol strings that we have started to include;
- full debug info. Symbol obfuscation was also changing full debug info
in LLVM metadata into line tables.
rdar://22330874, again.
Swift SVN r31473
We will need this to switch the darwin targets over to use ICU instead of going
to NSString for string operations. The public SDK does not contain the headers
for ICU - only the dylib.
For builds using a public SDK users can specify the path to an ICU install where
the headers can be found. If this path is specified the logic will not use
internal SDK variants.
Swift SVN r31471
This is a negative version of the flag
SWIFT_EXPERIMENTAL_EXTRA_REGEXP_FLAGS. The reason why an additional flag
is needed is that cmake does not support negative regexes in the regex
string itself. Instead you need to do:
if (NOT "..." MATCHES "...")
...
endif()
This suggests that we either needed to introduce more complexity into
SWIFT_EXPERIMENTAL_EXTRA_REGEXP_FLAGS or just introduce another flag. I
decided to go with the later.
Swift SVN r31417
This way they can be used from other projects, like LLDB. The downside
is we now have to make sure the header is included consistently in all
the places we care about, but I think in practice that won't be a problem,
especially not with tests.
rdar://problem/22240127
Swift SVN r31173
I am going to use this to enable the perftestsuite to compile .sib files next to
.o files. It will make it easier to work with the PerfTestSuite for the perf
engineers.
Swift SVN r30885
The compiler in the toolchain might be too old, and might not be able to
parse the new bitcode format from llvm trunk.
rdar://21014369
Swift SVN r30047
Fixes rdar://problem/21030937, which came about because CNErrorDomain
is missing availability information, so we generate a normal external
reference rather than a weak one.
Swift SVN r28824
... when building the overlay separately
We required this hack previously because we were not rebuilding
SwiftPrivate as a part of the overlay.
Swift SVN r28554
This ports staged changes on the Xcode 7 branch back to master.
This change requires 7A113 or greater, or 7A92k or greater.
rdar://problem/20730441
Swift SVN r28537
On OS X 10.10 and earlier, CoreImage is a sub-framework of QuartzCore.
Users of CoreImage use "import QuartzCore" and link against QuartzCore.
On OS X 10.11 (and in the OS X 10.11 SDK), CoreImage is a top-level
framework. Users of CoreImage use "import CoreImage" and would link against
CoreImage. Of course, QuartzCore continues to re-export CoreImage's API.
When backwards-deploying, we need to continue linking against QuartzCore,
but still need to bring in the overlay if you import CoreImage. That's
what this patch does.
rdar://problem/20196610
Swift SVN r28449
With bitcode enabled, the XCTest overlay fails to link because
XCTest.framework itself was not built with bitcode. For now, we should
not build this overlay with bitcode. It isn't embedded in apps.
rdar://problem/20884313
Swift SVN r28355
watchOS XCTest was temporarily moved to an AppleInternal path,
so we need to add it to the framework search path to continue to
build the watchOS overlay.
rdar://problem/20883853
Swift SVN r28353
Add the machinery for, but don't enable, adding LLVM bitcode
sections to Swift standard library and overlay dylibs.
Part of rdar://problem/20730441.
Swift SVN r28329
and link it properly. This is needed to embed LLVM bitcode sections
in the standard library and overlays. The linker doesn't support
embedded bitcode and reexport flags (among others).
rdar://problem/20750099
Swift SVN r28052
Replace ReST-flavored documentation comments with Markdown.
rdar://problem/20180412
In addition to full Markdown support, the following extensions are
supported. These appear as lists at the top level of the comment's
"document". All of these extensions are matched without regard to
case.
Parameter Outlines
------------------
- Parameters:
- x: ...
- y: ...
Separate Parameters
-------------------
- parameter x: ...
- parameter y: ...
- Note:
Parameter documentation may be broken up across the entire comment,
with a mix of parameter documentation kinds - they'll be consolidated
in the end.
Returns
-------
- returns: ...
The following extensions are also list items at the top level, which
will also appear in Xcode QuickHelp as first-class citizens:
- Attention: ...
- Author: ...
- Authors: ...
- Bug: ...
- Complexity: ...
- Copyright: ...
- Date: ...
- Experiment: ...
- Important: ...
- Invariant: ...
- Note: ...
- Postcondition: ...
- Precondition: ...
- Remark: ...
- Remarks: ...
- See: ...
- Since: ...
- Todo: ...
- Version: ...
- Warning: ...
These match most of the extra fields in Doxygen, plus a few more per request.
Other changes
-------------
- Remove use of rawHTML for all markup AST nodes except for those
not representable by the Xcode QuickHelp XSLT - <h>, <hr/>, and of
course inline/block HTML itself.
- Update the doc comment RNG schema to more accurately reflect Xcode
QuickHelp.
- Clean up cmark CMake configuration.
- Rename "FullComment" to "DocComment"
- Update the Swift Standard Documentation (in a follow-up commit)
- Update SourceKit for minor changes and link against cmark
(in a follow-up commit).
Swift SVN r27727
...and rename it to swift_common_llvm_config.
This is the function that acts like llvm_config but handles the LLVM build
being a different configuration from the Swift (or SourceKit) build, which
can be problematic for multi-configuration build schemes like Xcode.
There's also one fix here: LLVM dependencies for dylibs weren't being
properly added. (This is the "SHARED_LIBRARY" case near the bottom.)
Swift SVN r26631
Up to now we've been assuming that we have only one 32-bit target and
one 64-bit target per platform. There is a need to be able to build
armv7s for iOS, but assumptions abound in the organization of files per
architecture - tests, cmake targets, and installation.
- Build armv7s when building for iOS
- Use the actual architecture name, not blank or "/32" in all paths
related to architecture.
Testing: Clean buildbot incremental RA tests pass (requires a test
update in SourceKit as well).
rdar://problem/20206215
Swift SVN r26600
<rdar://problem/20180372>
Build cmark alongside llvm and clang.
If the clone doesn't exist, build-script-impl will clone it in the
workspace. Also update the README and update-checkout scripts.
Swift SVN r26364
