We have some problems on Linux where Glibc pulls in `<elf.h>` and then
we end up with conflicting definitions. Fix by using C++ interop and
putting our definitions into a namespace.
rdar://137201928
When building the standard library statically on Windows, we should not
use any __declspec(dllimport) or __declspec(dllexport) on the runtime
functions or data. Furthermore, we should internalise all of the
standard library functions so that they are not re-exported if used to
build a shared library. The code generation changes required for this
are easier to identify once a static SDK is available for Windows.
In the documentation for the `isLess(than:)` and `isLessThanOrEqualTo(_:)`
methods, a code sample isn't being formatted correctly due to it directly
following an unordered list. This change adds an additional message that
introduces the code sample, separating it from the list and allowing
the correct formatting to be applied.
This fixes a build warning:
```
swift/stdlib/public/Cxx/CxxDictionary.swift:168:9: warning: variable 'iter' was never mutated; consider changing to 'let' constant
```
This is a preliminary PR to transform nonescaping std::span parameters
to Swift's Span type in safe wrappers. To hook this up with
ClangImporter, we will need generalize the noescape attribute to
non-pointer types (PR is already in review). To transform potentially
escaping spans and spans in the return position, a follow-up PR will
add lifetime annotation support. This is a building block towards
rdar://139074571.
Under strict concurrency and memory safety, uses of `@unchecked
Sendable` conformances are considered unsafe. Diagnose the use sites,
not the declaration site.
* Make pointer bounds non-experimental
* Rename @PointerBounds to @_SwiftifyImport
* Rename filenames containing PointerBounds
* Add _PointerParam exception to stdlib ABI test
* Add _PointerParam to stdlib API changes
* Rename _PointerParam to _SwiftifyInfo
CxxSpan is trivial, but not immortal.
This initializer is diagnosed with an error after enabling trivial dependence
enforcement. Correct this with an _overrideLifetime call. This could be avoided
if we had a another way to tell the compiler that CxxSpan.__dataUnsafe()
produced a pointer with the same effective lifetime as the CxxSpan.
When a C++ foreign reference type is conformed to a Swift protocol via a Swift extension, trying to cast `any MyProtocol` to the foreign reference type crashes the runtime.
This was because `selectCasterForDest` wasn't handling C++ foreign reference types, and we were hitting `swift_unreachable`.
This change makes sure the runtime doesn't crash for such casts.
Notably, Swift doesn't have enough metadata to determine if the conditional cast actually succeeded. This is also a problem for CF types. Casting CF types in a similar fashion triggers a typechecker diagnostic. That diagnostic will be amended in a follow-up patch to also trigger for foreign reference types.
rdar://141227849
