As suggested by DaveZ. This was posted by me back on the review for
SE-0111, but it's become a useful post to reference for why Swift's
function arguments aren't just a tuple (in the language or in the
compiler).
Fixes a crash in IRGen
TODO: also fix the demangler/remangler part of this mangling change.
Currently it's not a problem because we never demangle such a symbol (it's even not round-trip checked in Mangler::verify).
rdar://problem/50405691
CMake supports the notion of installation components. Right now we have some
custom code for supporting swift components. I think that for installation
purposes, it would be nice to use the CMake component system.
This should be a non-functional change. We should still only be generating
install rules for targets and files in components we want to install, and we
still use the install ninja target to install everything.
Clean up the Windows build steps to use `md` and `cd`, remove the unnecessary `pushd`, `popd`, directly invoke `ninja` rather than invoking it through `cmake`.
This is duplicated by the Linux rules. The Windows Subsystem for Linux is not a unique environment, it is an Ubuntu environment running with a bridge into the NT kernel. There is nothing to be done to support it, just follow the Linux rules. The Windows documentation has been updated to point users to the Linux section.
The windows port has come far enough along that we can now recommend building with MSVC on Windows. This provides better debugging, faster builds, and better overall results.
Remove prelude as the documentation now covers the use of `cl` to build as it is stable and does a better job overall compared to `clang-cl` (better generated binaries, faster builds, better (working) debug information).
LLVM r355981 changed various intrinsic functions, including expect,
to require immediate arguments. Swift's _branchHint function has an
expected value that is passed in as an argument, so that it cannot
use LLVM's expect intrinsic. The good news is that _branchHint is only
ever used with immediate arguments, so we can just move the intrinsic
into _fastPath and _slowPath and use those instead of _branchHint.
As was noted in the documentation, the _fastPath and _slowPath names are
confusing but we have passed the point where we can simply rename them.
We could add new names but would still need to keep the old ones around
for binary compatibility, and it is not clear that it is worth the
trouble. I have removed that note from the documentation.
Add instructions to enable tests on Windows. This requires additional patches to libdispatch and Foundation to enable the build as well as run. But, this is in preparation for those changes to get merged and for others to replicate the test suite.
Corrections and improvements to the documentation to build on Windows. This includes:
- switching to `cl` for the swift build
- setting up the paths correctly
- correcting the instructions for XCTest builds
- setup to ensure that XCTest can be tested in the future
- fixes to actually get the swift tests to run on Windows
- removal of unnecessary arguments to libdispatch build
Add instructions for building libxml2. The libxml2 available for Windows is built against MinGW and requires iconv support. Simply build our own version of libxml2 to avoid the dependency.
Now that the flags have been fixed for the runtime build, we no longer need to ignore the overly verbose warnings. We now emit warnings which we should really cleanup.
