LLVM specifies that the result of fptosi and fptoui instructions are
undefined if the target type cannot represent the value exactly. On
IBM Z (s390x) these instructions currently saturate when overflow
occurs. This means that the round-trip used to detect overflow
succeeds in situations where the conversion is not actually exact.
For example, casting Int32.max to a Float32 via a sitofp instruction
results in Int32.max + 1. This is inexact. However if we then convert
back to an Int32 via a fptosi instruction the result is clamped to
Int32.max and so the round trip has resulted in the same value. We
therefore cannot rely on round trips alone to verify the exactness
of this cast portably.
This commit modifies the conversion routines so that they do not
rely on undefined behavior and avoid using round trips in general.
Modifies SILGen and the `Swift._diagnoseUnexpectedNilOptional` call to print a slightly different message for force unwraps which were implicitly inserted by the compiler for IUOs. The message is chosen based on the presence of certain flags in the `ForceValueExpr`, not on the type of the value being unwrapped.
We still had unavailable versions of these for floating-point types
only. We shouldn't need to keep these around, and can instead just
emit a helpful diagnostic for anyone that attempts to use them.
Unfortunately I don't see any way for the diagnostic to produce an
actual fix-it, so it just suggests '+= 1' or '-= 1' without actually
producing a fix.
Follow-up to "AllocStackHoisting: Don't hoist alloc_stacks in the presence of
an availability guard". The standard libary could use availability macros in the
future.
This disables inlinability of _stdlib_isOSVersionAtLeast. I don't see
value in making it inlinable as long as _swift_stdlib_operatingSystemVersion is
opaque.
rdar://41849700
Refactor out the implementation of index(_:offsetBy) and others from
BidirectionalCollection so that conformers can choose to invoke the
default implementations explicitly. This is very useful for types such
as String which have common fast-paths to check before falling back on
the general approach.
This is a slightly conservative precondition; when we re-work the FloatingPoint random computation in a more principled fashion, we can relax this to only requiring that .upperBound and .lowerBound are both finite. However, the current computation will break down unless this conservative condition is used, and this is future proof--we will only relax it going forward.
