We have already done the hard work of unwrapping the optionals
that represent the first and last pointer, and calling `self.count` does it all over again. Use the distance between the unwrapped pointers instead.
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
And set this option in various presets for buildbots.
Don't enable the checks by default because when linking against the OS library (which does not support COW checking) it will result in unresolved symbol errors.
So far it was handled by an availability checks against 9999 (which was a hack), but this does not work anymore.
Note, all this is only relevant for assert builds of the stdlib.
rdar://83673798
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.
Before this change, `RawRepresentable`'s custom `hashValue` implementation used to forward to `rawValue.hashValue`. (See https://github.com/apple/swift/pull/20705.) This sort of made sense at the time (`hash(into:)` was very new and `hashValue` was still in heavy use): it allowed raw representable values to return the exact same hash value as their `rawValue`, which some code used to (mistakenly) rely on. The big drawback of this is that to customize the Hashable implementation of a RawRepresentable type, people need to implement both `hashValue` and `hash(into:)` -- the former does not otherwise pick up customizations to the latter.
This change makes the default `RawRepresentable.hashValue` implementation call `self.hash(into:)`, just like it would on non-RawRepresentable types.
rdar://82651116
The law of exclusivity now allows us to remove the safety belt of swapping out self, getting rid of the need to create an empty array. (Which eliminates a swift_retain call.)
Before this change, the ABI checker didn't complain about missing @available
attributes on new APIs if the enclosing scopes of new APIs have
availability information. Instead, we should require explicit @available attributes
for new APIs to prevent them inheriting wrong availability information from a
preexisting scope.
rdar://81719628
These were defined for both FixedWidthInteger and FixedWidthInteger & SignedInteger for source compatibility with Swift 3; the latter set probably should have been removed when we stabilized the ABI, but were not. We can't easily remove them entirely (because we need them for ABI stability now), but we can mark them unavailable so that the typechecker doesn't have to consider them..
Previously we said that a type conforming to SignedNumeric allows positive and negative values, but that's nonsense. A type conforms to signed numeric if it has a negate() operation; it doesn't even have to have a notion of positive or negative values (for examples, see complex numbers, quaternions, integers mod n, etc).
Designated types were removed from the constraint solver in #34315, but they are currently still represented in the AST and fully checked. This change removes them as completely as possible without breaking source compatibility (mainly with old swiftinterfaces) or changing the SwiftSyntax tree. Designated types are still parsed, but they are dropped immediately and a warning is diagnosed. During decl checking we also still check if the precedence group is really a designated type, but only so that we can diagnose a warning and fall back to DefaultPrecedence.
This change also fixes an apparent bug in the parser where we did not diagnose operator declarations that contained a `:` followed by a non-identifier token.
