For using the improved condfail messages in the stdlib, we need a function, like precondition(), just taking a StaticString instead of a String for the message.
The existing (underscored) _precondition is a perfect fit for this, except that it's not printing the location info in debug builds.
This change makes _precondition() equivalent to precondition, just taking a StaticString as argument.
The other alternative would be to add another variant of precondition, just taking a StaticString. But we already have so many failure functions in Assert.swift, so adapting an existing one seems to be a better solution.
This effectively undos a change from 5 years ago which intentionally removed the location info from _precondition (rdar://problem/16958193). But this was at a time where swift was not open source yet. So I think today it's okay to always add location information, even if it's from inside the stdlib. It can be even very useful for expert users for looking up the location the stdlib source.
The SIL generation for this builtin also changes: instead of generating the cond_fail instructions upfront, let the optimizer generate it, if the operand is a static string literal.
In worst case, if the second operand is not a static string literal, the Builtin.condfail is lowered at the end of the optimization pipeline with a default message: "unknown program error".
This commit centralizes the code that converts variable length
tag values, stored in enum payloads and extra tag bytes, to and
from the 4-byte integer values that the runtime uses to represent
the enum case.
Note that currently big endian machines will store the tag value
in the first word of the destination. This reflects the current
behaviour of the compiler. I am however expecting to change this
so that the value is stored as a true variable-length big-endian
integer in the near future, so the tag value will be stored in
the last 4 bytes of payloads rather than the first 4 bytes like
they are on little-endian systems.
The memcpy in the type layout verifier was not correct for big-
endian systems. While we are here change 'long long' to a fixed
width unsigned type (uint64_t). It doesn't really make sense to
print the value as a signed number since we have zero extended
it from its original bit width using the memcpy.
`RefCount.h` can be included in a C context - e.g. building the
SwiftShims module. Restrict the C++ overloads to the C++ context only.
This partially improves the build for Windows ARM64.
This extends the WinSDK module definition further to better modularise
the headers. This should improve the header organisation as well as
setup additional autolink rules.
Inlinable and non-inlinable code can cause 5.1 code to intermix with
5.0 code on older OSes. Some (weak) invariants for 5.1 should only be
checked when the OS's code is 5.1 or later, which is the purpose of
_invariantCheck_5_1.
Applied to String.Index._isScalarAligned, which is a new bit
introduced in 5.1 from one of the reserved bits from 5.0. The bit is
set when the index is proven to be scalar aligned, and we want to
assert on this liberally in contexts where we expect it to be
so. However, older OSes might not set this bit when doing scalar
aligning, depending on exactly what got inlined where/when.
* Replace stdlib and test/stdlib 9999 availability.
macOS 9999 -> macOS 10.15
iOS 9999 -> iOS 13
tvOS 9999 -> tvOS 13
watchOS 9999 -> watchOS 6
* Restore the pre-10.15 version of public init?(_: NSRange, in: __shared String)
We need this to allow master to work on 10.14 systems (in particular, to allow PR testing to work correctly without disabling back-deployment tests).
For using the improved condfail messages in the stdlib, we need a function, like precondition(), just taking a StaticString instead of a String for the message.
The existing (underscored) _precondition is a perfect fit for this, except that it's not printing the location info in debug builds.
This change makes _precondition() equivalent to precondition, just taking a StaticString as argument.
The other alternative would be to add another variant of precondition, just taking a StaticString. But we already have so many failure functions in Assert.swift, so adapting an existing one seems to be a better solution.
This effectively undos a change from 5 years ago which intentionally removed the location info from _precondition (rdar://problem/16958193). But this was at a time where swift was not open source yet. So I think today it's okay to always add location information, even if it's from inside the stdlib. It can be even very useful for expert users for looking up the location the stdlib source.
The SIL generation for this builtin also changes: instead of generating the cond_fail instructions upfront, let the optimizer generate it, if the operand is a static string literal.
In worst case, if the second operand is not a static string literal, the Builtin.condfail is lowered at the end of the optimization pipeline with a default message: "unknown program error".
Seems that SwiftShims cannot import some system headers (checked by a
test in test/ParseableInterface/ModuleCache/SystemDependencies). So
adding <android/api-level.h> is not going to work.
The change reproduces the only piece necessary from the header, which is
interpreting that if no __ANDROID_API__ is defined, the level should be
the maximum allowed.
Be more aggressive about using the autolinking functionality of modules
on Windows. This makes it easier to use WinSDK in Swift as the link
dependencies are implicitly taken care of.
When the header was used in Android, the usage of __ANDROID_API__ was
not set if the compiler wasn't setting it externally. There was a check
for __ANDROID_API__, which defaulted to zero, and so it didn't pass. The
external function definition was not being done, but in C mode, it
didn't matter because implicit functions are allowed. That's not true in
C++ mode, which fails to compile any code that tries to include this
header.
The solution is including android/api-level.h which will define
__ANDROID_API__ to a very high value if it is not defined already (which
is the default behaviour in the NDK).
* Update example code to compile with Swift 5.0/5.1
Took inspiration from Filter.swift as to modern syntax to use, though didn't convert `private` properties to `internal`.
* simplify example code as requested
Removed private scope on properties to enable synthesized initializers; removed previously added explicit initializers; add necessary parameter label.
* Update stdlib/public/core/LazySequence.swift
remove ill advised usability change
Co-Authored-By: Xiaodi Wu <xiaodi.wu@gmail.com>
* Update stdlib/public/core/LazySequence.swift
Co-Authored-By: Xiaodi Wu <xiaodi.wu@gmail.com>
Generic parameters for a context are normally classified as "key",
meaning they have actual metadata provided at runtime, or non-key,
meaning they're derivable from somewhere else. However, a nested
context or constrained extension can take what would be a "key"
parameter in a parent context and make it non-key in a child context.
This messes with the mapping between the (depth, index) representation
of generic parameters and the flat list of generic arguments. Fix this
by (1) consistently substituting out extension contexts with the
contexts of the extended types, and (2) using the most nested context
to decide which parameters are key, instead of the context a parameter
was originally introduced in.
Note that (1) may have problems if/when extensions start introducing
their /own/ generic parameters. For now I tried to be consistent with
what was there.
rdar://problem/52364601
`StaticBinaryELF.cpp` was listed as an optional source but then unused
by any build target. As a result, it escaped detection that the file
was no longer in use.
the builtin.globalStringTablePointer to the new OSLog overlay.
Modify the new OSLog implementation to use this SPI instead of
`withCString` to pass the (compiler-generated) format string to
the C os_log_impl ABI.
Move the OSLogOptimization pass before constant propagation in
the pass pipeline so that the SPI and the builtin it uses can be
folded to a string_literal instruction.
Update OSLogTests to work with the changes in the implementation.
Unfortunately, `std::atomic` in msvcprt as of 14.21.27702 is broken for
double-width atomics on ARM64. This has been reported to Microsoft and
is going to be fixed in VC++ 2019u3. For the time being, add a partial
template specialisation for the two double-word sized types temporarily
as a workaround. This allows the standard library build to get further.
