Integer parsing seems to be very sensitive to inlining.
With simplifycfg, _parseInteger function gets bigger and ends up not being inlined
causing significant performance regression in the integer parsing benchmarks.
Add @always(__inline) to recover the performance.
It is no longer necessary to avoid using the `consume` keyword in inlinable
function bodies in the standard library in order to support older compilers.
Partially reverts https://github.com/apple/swift/pull/65599.
Resolves rdar://109165937.
We fix up the VWT pointer, but not the heap destroyer. This doesn't matter for classes which use ObjC refcounting, which is the common case for dynamic subclasses, because that doesn't use the heap destroyer pointer. But it does matter for classes that use native Swift refcounting, such as classes that don't inherit from NSObject, or actors.
rdar://113657917
This will be used to provide a safe overload of `std::vector::erase` in Swift.
`std::vector::erase` is not currently imported into Swift because it returns a C++ iterator.
rdar://113704853
`<xstddef>` was removed since MSVC 14.37. It isn't meant to be used by most users, but the reference will break all clients of `vcruntime`, including Swift standard library itself.
`_swift_stdlib_configure_console_mode` reverts console codepage on Windows using `atexit`, which is declared in `stdlib.h`.
Add the missing `#include <stdlib.h>` to unblock building Swift `stdlib` with MSVC v14.37 (Visual Studio 17.7).
This makes it possible to initialize `std::vector` from a Swift Sequence. This also conforms C++ vectors to `ExpressibleByArrayLiteral`, making it possible, for instance, to pass a Swift array to a C++ function that takes a vector of strings as a parameter.
rdar://104826995
Add a couple of submodules for these modules to further modularise the
headers. This might expose additional APIs now as some of these headers
would not have been indirectly included and wind up in the wrong module.
This makes the `stdint` module implicit which repairs the ability to
build some components. In order to accomplish this, we need to
potentially break the fragile Swift build system. Due to the incorrect
handling of compilers we need some workarounds to support
cross-compilation. This removes the injected system header paths when
building on Windows to ensure that the clang resource headers are not
following the system headers which breaks the modules as the clang
resources are dependent on the system headers when running in hosted
mode.
released memory.
Because the waitAll() group method is called before the group returns
from withTaskGroup and is used to ensure all tasks have completed before
we destroy the task group, this method is then immediately followed by
calling TaskGroup::destroy.
If we, as previously, first resume the waiting task and then attempt to
unlock the lock held by the group, we are in an unsafe situation with
racing the task group destroy() and the unlock().
Therefore, we must release the lock before we resume the waiting task.
This is currently a no-op since we don't auto-conform custom types to any kind of `MutableCollection` protocols: `UnsafeCxxMutableInputIterator` is only used for `std::map` conformance to `CxxDictionary` in the overlay. However, this will be useful in the future if we start conforming mutable C++ containers to certain Swift protocols: that way containers that use raw non-const pointers as iterators would be treated as mutable in Swift.
Support parsing the following format:
```
0x0000104b: DW_TAG_subprogram
DW_AT_specification (0x00000d23 "$s8CrashOpt6level1yyF")
DW_AT_inline (DW_INL_inlined)
```
_swift_addRefCountStringForMetatype and _swift_refCountBytesForMetatype diverged in the code that determines whether a type is a reference, causing the size number of ref count bytes to differ from the actually used bytes. This can cause early termination of the runtime interpreter functions, which in turn causes unbalanced reference counts.
rdar://112474091
