There are situations where you want to build against a libc that is out
of tree or that is not the system libc (Or for cross build scenarios).
This is a change for passing the -sdk and include paths for things like
this.
In the prior revision, this file combined two approaches:
- the old approach of doing some fun things with arrays and hoping
that any important public and internal generic symbols will happen
to be specialized
- the new approach of explicitly specializing a generic symbol by
annotating a dummy "proxy" function with the actual generic mangled
name, then calling that proxy with an argument of the type to be
specialized.
Unfortunately, the symbols exposed by SwiftOnoneSupport have become
ABI. Therefore, the old approach can break over time because changes
to the compiler and standard library will affect which symbols happen
to be specialized. It can be extremely difficult to debug why those
symbols have gone missing.
The new approach will work to ensure ABI stability, but the
implementation was incomplete and the style of implementation would
not work in many cases. It was still relying on the old approach to
cover the generic symbols that weren't explicitly specialized. Also,
it wasn't clear to anyone reading the source what specializations of
those generic symbols are intended and required by the ABI.
This commit completely removes the old approach to prespecialization.
All generic symbols required by the ABI are now explicitly listed.
There are now several different proxy functions declared as methods
within the generic type that they represent. The parameter types of
each proxy function now match the parameter types of the generic
function. This guarantees that the compiler can correctly apply the
proxy function's subsitution map to the generic function's generic
signature. For example, it now handles subtitution of dependent types
(like Range<T>), substitutions that are not in the first parameter
position, and subsitition that occur in multiple parameters.
The proxy functions are now directly invoked with the concrete
argument type needed for specialization. There's no other incidental
code.
It is now possible to read this source and understand which standard
library functions need to be prespecialized on which types.
The purpose of this module is to prespecialize generic methods in the
stdlib. All symbols exposed by the ABI must be explicitly identified
to maintain ABI compatibility. Some of those ABI-exposed symbols
reference internal stdlib types.
Given that we want the prespecialized code to live in the separate
SwiftOnoneSupport library, and we want the module to explicitly list
all the symbols required for ABI stability, there's no way around
disabling access control when building it. In fact, that flag does
precisely what we want.
This should be harmless because
- no one imports SwiftOnoneSupport.swiftmodule
- these internal symbols were always being exposed in
SwiftOnoneSupport.dylib, so nothing changes there
When compiling SwiftOnoneSupport, issue errors for missing functions which are expected in the module.
This ensures ABI compatibility.
rdar://problem/48924409
It's very unlikely that those functions are really referenced by Onone executables, but we want to be ABI compatible.
Also, there is no guarantee that this version of SwiftOnoneSupport will always trigger all symbol to be pre-specialized.
If the optimizer changes, we might need to add other explicit pre-specializations of internal stdlib symbols.
rdar://problem/48924409
Magic symbols of the form $ld$install_name$os9.0$@rpath/libswiftCore.dylib tell the linker to use that install name when targeting that OS version. Use these symbols to specify an @rpath install name for all back-deployment libraries when targeting watchOS 2.0-5.1, iOS 7.0-12.1, and macOS 10.9-10.14.
rdar://problem/45027809
The debug build of the standard library on Windows does not generate the
import library for SwiftOnoneSupport which prevents the build of debug
programs against the debug runtime. Because the linker must find the
import library in order to satisfy the forced link that we emit for the
link against the SwiftOnoneSupport library, without this, the build is
not usable. Furthermore, this requires a debug build of the runtime
since in the optimized build, the interfaces that this library provides
are not provided by swiftCore and this supplements the library to allow
building the debug program.
The key thing here is that all of the underlying code is exactly the same. I
purposely did not debride anything. This is to ensure that I am not touching too
much and increasing the probability of weird errors from occurring. Thus the
exact same code should be executed... just the routing changed.
TBD validation is effectively an expensive assertion, and is currently only
tuned for Apple platforms. However, we don't want it to regress more, and it
would be nice to start getting validation from people using master
snapshots. Together, this means that turning it on by default for the cases
mentioned above is an appropriate course of action.
At the very least, this has the benefit of running validation across the stdlib,
the overlays and the whole testsuite on each build, so people making changes to
the compiler that change symbols are hopefully alerted.
One limitation here is that this is only validating that the TBD is a superset
of the true set of symbols: it could include spurious symbols that aren't
actually in the binary. This case is less problematic for Swift than symbols
missing from the TBD file, and so we've focused energy on this. Once we've fixed
the extra-symbols problems and are confident in it, this validation can be
upgraded to validate that too.
Half of rdar://problem/40431434.
In theory there could be a "fixed-layout" enum that's not exhaustive
but promises not to add any more cases with payloads, but we don't
need that distinction today.
(Note that @objc enums are still "fixed-layout" in the actual sense of
"having a compile-time known layout". There's just no special way to
spell that.)
These changes caused a number of issues:
1. No debug info is emitted when a release-debug info compiler is built.
2. OS X deployment target specification is broken.
3. Swift options were broken without any attempt any recreating that
functionality. The specific option in question is --force-optimized-typechecker.
Such refactorings should be done in a fashion that does not break existing
users and use cases.
This reverts commit e6ce2ff388.
This reverts commit e8645f3750.
This reverts commit 89b038ea7e.
This reverts commit 497cac64d9.
This reverts commit 953ad094da.
This reverts commit e096d1c033.
rdar://30549345
This patch splits add_swift_library into two functions one which handles
the simple case of adding a library that is part of the compiler being
built and the second handling the more complicated case of "target"
libraries, which may need to build for one or more targets.
The new add_swift_library is built using llvm_add_library, which re-uses
LLVM's CMake modules. In adapting to use LLVM's modules some of
add_swift_library's named parameters have been removed and
LINK_LIBRARIES has changed to LINK_LIBS, and LLVM_LINK_COMPONENTS
changed to LINK_COMPONENTS.
This patch also cleans up libswiftBasic's handling of UUID library and
headers, and how it interfaces with gyb sources.
add_swift_library also no longer has the FILE_DEPENDS parameter, which
doesn't matter because llvm_add_library's DEPENDS parameter has the same
behavior.
This reverts commit 1b3d29a163, reversing
changes made to b32424953e.
We're seeing a handful of issues from turning on inlining of generics,
so I'm reverting to unblock the bots.
In response to [SR-3334], which pointed out a large cost to iteration over
ReversedRandomAccessCollections at optimization level -Onone. By adding
iteration through a.reversed() in the _Prespecialize struct, we can get to
about the same performance as forward iteration.
As a first step to allowing the build script to build *only*
static library versions of the stdlib, change `add_swift_library`
such that callers must pass in `SHARED`, `STATIC`, or `OBJECT_LIBRARY`.
Ideally, only these flags would be used to determine whether to
build shared, static, or object libraries, but that is not currently
the case -- `add_swift_library` also checks whether the library
`IS_STDLIB` before performing certain additional actions. This will be
cleaned up in a future commit.
Pre-specializations were only used by Onone builds, but were kept inside the standard library dylyb anyways. This commit moves all the pre-specializations into a dedicated Swift module and a dynamic library, which are only used by Onone builds.
This reduces the code size of libswiftCore.dylib by 4%-5%.
Pre-specializations were only used by Onone builds, but were kept inside the standard library dylyb anyways. This commit moves all the pre-specializations into a dedicated Swift module and a dynamic library, which are only used by Onone builds.
This reduces the code size of libswiftCore.dylib by 5%.
