If some object file doesn't contain a section of the name '.note.GNU-stack',
the linker make the stack executable. We append the section to swift_begin.o
and swift_end.o because don't need executable stack.
(reference: http://en.chys.info/2010/12/note-gnu-stack/)
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.
The use of `std::make_tuple` requires the declaration of the function which is
provided by the C++ standard header `tuple`. This would get implicitly included
by one of the other C++ headers on the currently tested libraries, but does not
occur with the Microsoft C++ library. Add the missing include.
`WIN32_LEAN_AND_MEAN` prevents "rarely-used" headers from being pulled in. This
significantly reduced preprocessor pressure, speeding up compile. It also
reduces the amount of cruft pulled in by the Windows.h.
`NOMINMAX` ensures that the `min` and `max` macros are not defined. These
macros collide with the use of `min` and `max` from C++ in certain cases: e.g.
`std::limits<T>`.
Use the C++11 std::this_thread::yield to abstract away platform specific
differences for yield execution time. This makes the code more portable to
non-POSIX environments (i.e. Windows). NFC.
Rather than duplicating the constant value, use the `sizeof` operator to have
the value propogate from the static buffer allocation. Any standards conforming
implementation of `snprintf` will null-terminate the output unless the buffer is
NULL (a zero-sized buffer is passed to the call). On Windows, where this is not
the case, the function is named `_snprintf` which ensures that we do not
accidentally end up with the incorrect behaviour.
This patch is for libswiftCore.lib, linking with the library set of Visual Studio 2015. Clang with the option -fms-extension is used to build this port.
This is the approved subpatch of a large patch.
Declarations with protected visibility are assumed to be defined
within the current linkage unit, so we have to use default visibility
if we don't know that we're building that. Teach the shim
visibility header to only use protected visibility when the
__SWIFT_CURRENT_DYLIB macro is defined, and define it when building
the standard library. Eventually we should change
SWIFT_RUNTIME_STDLIB_INTERFACE and SWIFT_RUNTIME_EXPORT to be
parameterized by the defining dylib so that this works for all the
overlay stubs, too; for now, special-casing swiftCore is necessary
to fix the LInux build.
Part 1: Generic SIL Boxes always have instatiated metadata with kind
HeapGenericLocalVariable, which includes a metadata pointer for the
boxed type.
Part 2, after this, is to provide some kind of outgoing pointer map for
fixed heap boxes, whose metadata may be shared among different but
destructor-compatible types.
rdar://problem/26240419
Previously, we were using backtrace_symbol and then parsing/modifying its
output. By just using dladdr directly, we have a cleaner and more robust
solution.
rdar://25064742
This is a purely mechanical change replacing the attributes with the reserved
spelling. Compilers are to not error when they encounter a reserved spelling
for an attribute which they do not support.
_SwiftNativeNSError is a runtime-private subclass, and NSError's inherited NSCoding implementation doesn't handle the Swift payload of bridged errors. We can't really archive arbitrary Swift values anyway yet, so just archive bridged NSError subclasses as regular NSErrors. Fixes rdar://problem/23051728.
The default implementation from NSObject doesn't know how to copy the Swift error payload, and the object's immutable anyway, so we just need to retain and return the object we already have.
The general rule here is that something needs to be SWIFT_CC(swift)
if it's just declared in Swift code using _silgen_name, as opposed to
importing something via a header.
Of course, SWIFT_CC(swift) expands to nothing by default for now, and
I haven't made an effort yet to add the indirect-result / context
parameter ABI attributes. This is just a best-effort first pass.
I also took the opportunity to shift a few files to just implement
their shims header and to demote a few things to be private stdlib
interfaces.
It has been fairly easy to cause the runtime to crash on multithreaded read-read access to weak references (e.g. https://bugs.swift.org/browse/SR-192). Although weak references are value types, they can get elevated to the heap in multiple ways, such as when captured by a closure or when used as a property in a class object instance. In such cases, race conditions involving weak references could cause the runtime to perform to multiple decrement operations of the unowned reference count for a single increment; this eventually causes early deallocation, leading to use-after-free, modify-after-free and double-free errors.
This commit changes the weak reference operations to use a spinlock rather than assuming thread-exclusive access, when appropriate.
With this change, the crasher discussed in SR-192 no longer encounters crashes due to modify-after-free or double-free errors.
Fixes a leak when a bridgeable value type is dynamically cast to a class type, and the cast fails, for instance:
```
let x: Any = "string"
x is NSNumber
```
We would fail to release the bridging object after attempting the cast.
