This removes the explicit tree structure reference in the stubs to
locate the shims. Instead, it expects that the `SwiftShims` directory
will be added to the header search path.
In debug configurations, fatal error messages include file & line number information. This update presents this information in a format matching the diagnostic conventions used by the compiler, which can be a slight productivity boost.
Code compiled with optimizations enabled (which is most production code) does not output this information, so it isn’t affected by this change.
Original format:
Fatal error: A suffusion of yellow: file calc.swift, line 5
New format:
calc.swift:5: Fatal error: A suffusion of yellow
Resolves rdar://68484891
Most SwiftShims were put in the swift namespace in C++ mode which broke certain things when importing them in a swift file in C++ mode. This was OK when they were only imported as part of the swift runtime but, now they are used in C++ mode both in the swift runtime and when C++ interop is enabled.
This broke when C++ interop was enabled because the `Swift` module contains references to symbols in the SwiftShims headers which are built without C++ interop enabled (no "swift" namespace). But, when C++ interop is enabled, the SwiftShims headers would put everything in the swift namespace meaning the symbols couldn't be found in the global namespace. Then, the compiler would error when trying to deserialize the Swift module.
The message is available in the debugger (or in Xcode), but it
increases the chances that the user will see it if it's also been
logged at the time the debugger takes over.
* Unify the capitalization across all user-visible error messages (fatal errors, assertion failures, precondition failures) produced by the runtime, standard library and the compiler.
* Update some more tests to the new expectations.
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.
...and explicitly mark symbols we export, either for use by executables or for runtime-stdlib interaction. Until the stdlib supports resilience we have to allow programs to link to these SPI symbols.
Many of the report* entry points are specific to the stdlib assert implementation, so belong in the stdlib. Keep a single `reportError` entry point in the runtime to handle the CrashReporter/ASL interface, and call down to it from the assert implementation functions.
