Clean up the submodules in visualc to not export all imported modules.
The one special case is `vcruntime` which re-exports `SAL` due to a
dependency in the headers. The import of `visualc` however will
re-export all submodules to keep the current behaviour. This is
required to get the ARM64 SDK building on newer MSVC toolsets.
This adds a new reflection record type carrying spare bit information for multi-payload enums.
The compiler includes this for any type that might need it in order to accurately reflect the contents of the enum. The RemoteMirror library will use this if present to determine how to project the contents of the enum. If not present (for example, in older binaries), the RemoteMirror library falls back on an internal calculation of the spare bitmask.
A few notes:
* The internal calculation is not perfect. In particular, it does not support MPEs that contain other enums (e.g., optionals). It should accurately refuse to project any MPE that it does not correctly support.
* The new reflection field is designed to be expandable; this might someday avoid the need for a new section.
Resolves rdar://61158214
This migrates OpenBSD to use the single-header Glibc modulemap proposed
and implemented in #32404, and necessitates introducing some missing
headers for building Foundation added in #38341.
Additionally, incorporate nullability annotations in SwiftShims per
When building with a prebuilt Clang, the changes introduced in #40707
supposed that the toolchain was in its final path.
When building in stages (first the toolchain, then the standard
library), the toolchain might not be in the final path, and the created
symlink will point to a machine-local path that does not make sense.
The changes introduced should not modify the existing behaviour
introduced by #40707, but should allow customizing the final
installation target using the CMake cached variable for those setups
that need the flexibility.
This module used to be a private implementation detail of the Distpatch overlay on Apple platforms, and swift-corelibs-libdispatch elsewhere.
Darwin hasn't been using this module for a couple years now, and swift-corelibs-dispatch stopped using it with https://github.com/apple/swift-corelibs-libdispatch/pull/592. We are now free to remove it from the Swift toolchain -- which is good, as it contains declarations that are specific to Dispatch, and the compiler/stdlib is not the right place to maintain them.
This used to be a private implementation detail of the XCTest overlay.
This module has been unused since the Xcode 12.5 release, but we temporarily kept it in the toolchain in case a downloadable toolchain gets used with an older Xcode. (The module used to be imported by the XCTest overlay interface, so its removal would have made it tricky to import XCTest in that scenario.)
Including the 13.3 beta, there have now been seven Xcode releases since the last one that imported this module, and the compiler/stdlib repository no longer supports building with Xcode 12.4 or below. It seems reasonable to stop installing this module on the toolchain now.
rdar://80552912
Unfortunately using the convenient "bootstrapping0-all", etc. custom targets does not work.
For some reason it does not cause a dependent file (like libswift's SIL.o) being rebuilt when a depenency (like swift-frontend from the previous bootstrapping stage) changes.
Instead we have to list al library- and executable-targets explicitly.
* Generate Unicode data for Scalar Binary Properties
* Use native scalar binary property lookup
* Add _BinaryProperties to Scalar Properties
narrow access control
* Upgrade the notice to a warning in UnicodeScalarProperties
Windows objects to the multiple different aliases for
`swift_isStackAllocationSafe`. Use strong linkage on all non-ABI stable
targets. This should repair the Windows build and matches the
conditional emission in the stdlib.
Thanks to @lorentey for the discussion around how to handle this and the
pointer to where this was getting introduced!
Don't build the swiftCore module files in the bootstrapping phases. Instead use the module files in the SDK.
This reduces the build time overhead from 3min -> 30seconds.
* Implement GraphemeWalker that does native grapheme breaking
* Bridged strings use native grapheme breaking for forward strides
* Implement bidirectional native grapheme breaking for native and foreign strings
* Remove ICU's grapheme breaking support
* Use UnicodeScalarView to implement GraphemeWalker
use an Iterator approach
remove Iterator conformance
* Incorporate Michael's feedback
more comments addressed
fix crlf bug
* Try bringing back some old fast paths
* Parameterize nextBoundary and previousBoundary
Parameterize nextBoundary and previousBoundary
* Implement Michael's suggestions
Adds two new IRGen-level builtins (one for allocating, the other for deallocating), a stdlib shim function for enhanced stack-promotion heuristics, and the proposed public stdlib functions.
This is for the 'freestanding' build to stop assuming the platform has argc/argv.
- Introduce a new sub-library, libswiftCommandLineSupport.a
- Move stubs/CommandLine.cpp into this library
- Conditionally embed it into libswiftCore
- Conditionally embed it into libswiftPrivateLibcExtras if not in libswiftCore to support testing
- Add SWIFT_STDLIB_HAS_COMMANDLINE CMake (and build-script) flag
Fixes a couple of compiler warnings that occur frequently when building the compiler:
- Copy the nullability annotation definitions from `Visibility.h` to `BridgedSwiftObject.h` and wrap all code that contains nullability annotations in `SWIFT_BEGIN_NULLABILITY_ANNOTATIONS` and `SWIFT_END_NULLABILITY_ANNOTATIONS` (supressing the warning `type nullability specifier '_Nullable' is a Clang extension [-Wnullability-extension]`)
- Suppress warnings about using `$` (mangling prefix) as an identifier using pragmas (supressing the warning `'$' in identifier [-Wdollar-in-identifier-extension]`)
- Change the macro condition of `SWIFT_NODISCARD` from `__cplusplus >= 201402l` (which checked for >= C++14) to `__cplusplus > 201402l`. This appears to have been a copy-paste error from `LLVM_NODISCARD` (supressing the warning `use of the 'nodiscard' attribute is a C++17 extension [-Wc++17-extensions]`)
Adding build modes for libswift: off, hosttools, bootstrapping, bootstrapping-with-hostlibs
The two bootstrapping modes are new. For details see libswift/README.md
_isClassType is mainly called by compiler-generated code, but it's also
called by stdlib. The call-site of stdlib used @_silgen_name to link the
function, so it's called through swiftcc. However its cc is defined as
C-cc, so caller and callee used different cc.
This patch adds C-compatible decl of swift_isClassType in shims so that
it can be called by stdlib with C-cc.
This change doesn't break ABI because `_isClassType` in stdlib was
defined as internal API.
The Windows ARM64 builds can require a newer build of VS2019 (update 3
or newer). This removes the workaround from the shims. This was needed
for older installations of Visual Studio and no longer works with Visual
Studio 2022.
The corresponding overlays are maintained outside of this repository, and they haven’t been importing these shims for years.
SDKs that shipped between Xcode 10.2 and Xcode 11 (or so) contained overlay modules that imported these shims modules, so future toolchain builds won’t work correctly with those SDKs. (This is fine! We do not expect toolchain builds to work with years old Xcode installations anyway.)
Only relevant for -Xfrontend -enable-copy-propagation in debug builds.
It's only an experimental mode for now for shrinking lifetimes while
providing lldb an easy way to report a friendly error.
Goals:
- two repetitive digits that don't look like garbage
- less than a page, so it can never be a real pointer
- reserve as many low bits as possible so it can't be a tagged pointer
- not used by any other memory smashers
0x440 is 64-byte aligned which is plenty for any conceivable object
allocator.
