This TODO has existed since the introduction of the Windows platform and
has not been addressed. The implementation at this point is well tested
in practice. Clean up the warning message and style and remove the
warning.
`stdint.h` should be picked up from `clang/lib/Headers`, but is instead
being picked up by the system libc++. There's no C++ stdlib being used
here, so just exclude it.
Resolves rdar://134584685.
- when compiling embedded cross compile target standard libraries, include AVR
- add 16-bit pointer as a conditional compilation condition and get the void pointer size right for gyb sources
- attempt to fix clang importer not importing __swift_intptr_t correctly on 16 bit platforms
- changed the unit test target to avr-none-none-elf to match the cmake build
[AVR] got the standard library compiling in a somewhat restricted form:
General
- updated the Embedded Runtime
- tweaked CTypes.swift to fix clang import on 16 bit platforms
Strings
- as discussed in https://forums.swift.org/t/stringguts-stringobject-internals-how-to-layout-on-16-bit-platforms/73130, I went for just using the same basic layout in 16 bit as 32 bit but with 16 bit pointers/ints... the conversation is ongoing, I think something more efficient is possible but at least this compiles and will probably work (inefficiently)
Unicode
- the huge arrays of unicode stuff in UnicodeStubs would not compile, so I skipped it for AVR for now.
Synchronization
- disabled building the Synchronization library on AVR for now. It's arguable if it adds value on this platform anyway.
This will avoid CMake configuration errors in `llvm_process_sources`
in configurations that build only the the standard library for embedded.
Addresses rdar://130229502
WebAssembly does not support _Float16 type, so we need to guard the use
of the type. Unfortunately, Clang does not provide a good way to detect
the support of _Float16 type at compile time, so just disable for wasm
targets.
We can easily test all 2**16 values, so let's do it. Also now _Float16 is properly supported in clang, so we can pass arguments to CPP that way, which lets us get snan right on more platforms.
We should always be using `<errno.h>`, not `<sys/errno.h>`. The
former is part of the C standard. The latter is a non-standard
header that happens to be present on some systems.
rdar://123507361
Static read-only arrays didn't work when passed to ObjectiveC as NSArray.
The storage class of static read-only arrays doesn't carry information about the Element type.
The new `__SwiftDeferredStaticNSArray` is generic over the element type and doesn't have to rely on the element type information of the array storage.
rdar://94185998
`_swift_stdlib_configure_console_mode` reverts console codepage on Windows using `atexit`, which is declared in `stdlib.h`.
Add the missing `#include <stdlib.h>` to unblock building Swift `stdlib` with MSVC v14.37 (Visual Studio 17.7).
The alias defined here with the `.set` directive doesn't actually define a symbolic alias
that the linker respects in all cases. The resulting standard library dylib _does_ contain a
reference to the aliased symbol with the correct value, but the resulting variable is not actually
considered relocatable by the linker. Thus, its value may not always get fixed up properly.
Work around this by dropping the alias for now - directly use the type metadata for Swift.__EmptyArrayStorage
instead.
rdar://100288247
This replaces a number of `#include`-s like this:
```
#include "../../../stdlib/public/SwiftShims/Visibility.h"
```
with this:
```
#include "swift/shims/Visibility.h"
```
This is needed to allow SwiftCompilerSources to use C++ headers which include SwiftShims headers. Currently trying to do that results in errors:
```
swift/swift/include/swift/Demangling/../../../stdlib/public/SwiftShims/module.modulemap:1:8: error: redefinition of module 'SwiftShims'
module SwiftShims {
^
Builds.noindex/swift/swift/bootstrapping0/lib/swift/shims/module.modulemap:1:8: note: previously defined here
module SwiftShims {
^
```
This happens because the headers in both the source dir and the build dir refer to SwiftShims headers by relative path, and both the source root and the build root contain SwiftShims headers (which are equivalent, but since they are located in different dirs, Clang treats them as different modules).
* Implement String.WordView
* Add isWordAligned bit
* Hide WordView for now (also separate Index type)
add bidirectional conformance
Fix tests
* Address comments from Karoy and Michael
* Remove word view, use index methods
* Address Karoy's comments
aaa
* `__swiftImmortalRefCount`: The bit pattern of the ref-count field of immortal objects
* `__swiftStaticArrayMetadata`: The metadata used for static arrays.
There's no guarantee that e.g. pthread_key_t is an integral type. It could
be some kind of struct, or some other thing that isn't valid as a template
argument.
rdar://90776105
