... 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
Runtime should use LINK_LIBRARIES to link to ICU, since it is a static
archive, and we need this link dependency to be propagated to the
libswiftSwiftCore library. I have no idea why it linked correctly
worked before.
Swift SVN r25881
The standard library has grown significantly, and we need a new
directory structure that clearly reflects the role of the APIs, and
allows future growth.
See stdlib/{public,internal,private}/README.txt for more information.
Swift SVN r25876
disabling the standard library
In almost all cases, CMake will happily operate on undefined variables,
treating them as empty, but for some reason list(REMOVE_ITEM) is an
exception.
Swift SVN r25835
The reason why this is necessary is that I need to update parts of the runtime
for +0 self. I am going to use a -D flag to do this implying I need the build
system's help. Since I already have the flag I am also going to wire up the
emission of +0 self code from the compiler to be triggered off this as well.
It is of course disabled by default.
<rdar://problem/20080934>
Swift SVN r25833
Now if you want to get these dynamic metrics from the runtime all you
need to do is:
1. Configure Swift with -DSWIFT_RUNTIME_ENABLE_DTRACE=YES
2. Run your routine with the command:
sudo dtrace -s ./utils/runtime_statistics.d -c "$MY_COMMAND_LINE"
After your app finishes running, it will dump out the counts. This is a
much more efficient and low maintenance way to get such statistics than
custom instrumenting the code.
Nothing is changed if -DSWIFT_RUNTIME_ENABLE_DTRACE is not set.
Swift SVN r25264
This adds support to build-script and cmake scripts for cross-compiling the host tools in addition to stdlib.
To cross-compile, build-script-impl now accepts --cross-compile-tools-deployment-targets with a space separated list of targets to cross compile host Swift tools for.
For example: $ build-script ...other-args... -- --cross-compile-tools-deployment-targets="iphoneos-arm64 iphoneos-armv7".
When installing cross-compiled tools, it now also merges and runs lipo to produce fat binaries by merging the cross-compiled target architectures.
Swift SVN r24712
The SLPVectorizer is now faster (rdar://problem/19430955): it needs 2.5% of stdlib compile time.
Related radar: rdar://problem/19433841
Swift SVN r24511
This shaves around 5 seconds off the stdlib build if you're using a
release/no-assert LLVM (so around 12.5% of total time if you're also
using a release/no-assert swift, or around 4% of total time if you're
using a debug/assert swift).
The underlying LLVM issue is tracked by rdar://problem/19430955.
I saw no significant reproducible performance loss due to this change.
Resolves rdar://problem/19431821.
Swift SVN r24342
Often times one wants to pass certain flags to swift when building
specific libraries and not others. This has in the past required
manually modifying the cmake system. This new option allows one to use
string regexps based on the module_name of a library to enable and
disable various flags. The way this works is you pass the following into
build-script:
--extra-swift-options="${REGEX1};${FLAGS1_WITH_SEMICOLONS_ESCAPED}"
--extra-swift-options="${REGEX2};${FLAGS2_WITH_SEMICOLONS_ESCAPED}"
--extra-swift-options="${REGEX3};${FLAGS3_WITH_SEMICOLONS_ESCAPED}"
--extra-swift-options="${REGEX4};${FLAGS4_WITH_SEMICOLONS_ESCAPED}"
--extra-swift-options="${REGEX5};${FLAGS5_WITH_SEMICOLONS_ESCAPED}"
Every library that matches REGEPN will have FLAGSN_... appended to their
swift flags. For instance if I did the following:
build-script --extra-swift-options="Swift;-Xfrontend\;-sil-print-pass-name" --extra-swift-options='^Swift$;-Xllvm\;-debug-only=sil-arc-opts" ...
CMake will output the following:
-- Matched 'Swift' to module 'Swift'. Compiling Swift with special flags: -Xfrontend;-sil-print-pass-name
-- Matched '^Swift$' to module 'Swift'. Compiling Swift with special flags: -Xllvm;-debug-only=sil-arc-opts
-- Matched 'Swift' to module 'SwiftExperimental'. Compiling SwiftExperimental with special flags: -Xfrontend;-sil-print-pass-name
-- Matched 'Swift' to module 'SwiftStructures'. Compiling SwiftStructures with special flags: -Xfrontend;-sil-print-pass-name
-- Matched 'Swift' to module 'SwiftStructuresGraphBFS'. Compiling SwiftStructuresGraphBFS with special flags: -Xfrontend;-sil-print-pass-name
stating which regexp was matched, the module it was matched to and the
added flags. This ensures that one only gets matches for what one wants.
Swift SVN r24271
This worked in standalone build by creating a directory that never got used but it failed in a non-standalone build.
Fix tracked with Dmitri's help.
Swift SVN r24180
