Also, fix two files that managed to use Windows API without
importing `WinSDK` as a result of the leakage caused by including
`windows.h` from `codeview.h`.
rdar://101623384
On-crash backtracing is basically there for 64-bit Windows. It
won't work on 32-bit because of a Swift compiler issue, and there
is a little more work to do yet, but it is now working!
rdar://101623384
This doesn't have a working symbolicator yet, but it does build and
it can obtain a basic backtrace.
It also doesn't include a working `swift-backtrace` program yet.
rdar://101623384
We should expose the demangle functionality; It's been widely used by
calling into internal _swift_demangle and instead we should offer a real
API. It's also already used in the Runtime module already when forming
backtraces.
[Previous
discussions](https://forums.swift.org/t/demangle-function/25416/15)
happened between 2019 and 2024, and just never materialized in a
complete implementation and proposal.
Right now, even more tools are in need of this API, as we are building
continious profiling solutions etc, so it is a good time to revisit this
topic.
This PR is roughly based off @Azoy's
https://github.com/swiftlang/swift/pull/25314/files#diff-fd379a721cc9a1c9ef6486eae713e945da842b42170d4d069029a57334371eba
from 2019, however it brings it over to the new Runtime module which is
a great place to put this functionality - even Backtrace had to recently
reinvent calling the demangling infra in this module.
Pending SE review, [proposal
here](https://github.com/swiftlang/swift-evolution/pull/2989).
cc @azoy @al45tair
---------
Co-authored-by: Alastair Houghton <alastair@alastairs-place.net>
Move the backtracing code into a new Runtime module. This means renaming
the Swift Runtime's CMake target because otherwise there will be a name
clash.
rdar://124913332
