Always run explicit `Sendable` checks on public types and suppress
warning printing by default instead of using a special compiler argument.
Resolves: rdar://162394810
- Add SPI availability information to `APIAvailability` from attribute
`@_spi_available`.
- Correctly obtain effective availability for nested declarations
without immediate availability attributes.
Resolves rdar://159702280
<!--
If this pull request is targeting a release branch, please fill out the
following form:
https://github.com/swiftlang/.github/blob/main/PULL_REQUEST_TEMPLATE/release.md?plain=1
Otherwise, replace this comment with a description of your changes and
rationale. Provide links to external references/discussions if
appropriate.
If this pull request resolves any GitHub issues, link them like so:
Resolves <link to issue>, resolves <link to another issue>.
For more information about linking a pull request to an issue, see:
https://docs.github.com/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue
-->
<!--
Before merging this pull request, you must run the Swift continuous
integration tests.
For information about triggering CI builds via @swift-ci, see:
https://github.com/apple/swift/blob/main/docs/ContinuousIntegration.md#swift-ci
Thank you for your contribution to Swift!
-->
In embedded mode, some things call retain/release using the C++ declarations, but the implementations are in Swift. The Swift implementations don't use preservemost, so the C++ declarations must not declare preservemost in that context.
rdar://163940783
Fix crash when creating a Span from an empty InlineArray whose storage
is only byte-aligned. #85265.
---------
Co-authored-by: Guillaume Lessard <glessard@tffenterprises.com>
This fixes the following tests which are now crashing due to hitting
unreachable "no buffer containing location found" in
`SourceManager::findBufferContainingLoc`:
- attr/attr_dynamic_member_lookup.swift
- AutoDiff/Sema/DerivativeRegistrationCrossModule/main.swift
- Constraints/construction.swift
- Constraints/members.swift
- NameLookup/accessibility.swift
- Sema/call_as_function_simple.swift
The root cause of the crash is as follows. All the tests involve
emitting `InaccessibleMemberFailure` error diagnostic (see
`InaccessibleMemberFailure::diagnoseAsError`). When `DeclNameLoc
nameLoc` is initialized via default constructor and is not re-assigned
with smth meaningful later, the check `nameLoc.isValid()` returns `true`
even though it should be `false`. It turns out that we treat `const void
*LocationInfo` as `SourceLoc` and hope that if `LocationInfo` is
`nullptr`, casting this to `SourceLoc` would produce a "default"
`SourceLoc` with `Pointer` member set to `nullptr`. But such a cast (see
`getSourceLocs()` member of `DeclNameLoc`) is undefined behavior. So,
the compiler assumes that `Pointer` member of `SourceLoc` we try to cast
to is not `nullptr` (due to strict aliasing rule), which leads to
`nameLoc.isValid()` being mistakenly computed as `true`.
This patch resolves the issue by handling this special case separately.
Inspired by #84826, I've dusted off and completely reworked a native
implementation of integer-to-string conversion.
Besides existing tests in this repository, the core of the
implementation has been comprehensively tested in a separate package for
all bases between 2–36 to demonstrate identical output for all 8-bit and
16-bit values, and for randomly generated 32-bit, 64-bit, and 128-bit
values.
Resolves#51902.
<!--
If this pull request is targeting a release branch, please fill out the
following form:
https://github.com/swiftlang/.github/blob/main/PULL_REQUEST_TEMPLATE/release.md?plain=1
Otherwise, replace this comment with a description of your changes and
rationale. Provide links to external references/discussions if
appropriate.
If this pull request resolves any GitHub issues, link them like so:
Resolves <link to issue>, resolves <link to another issue>.
For more information about linking a pull request to an issue, see:
https://docs.github.com/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue
-->
<!--
Before merging this pull request, you must run the Swift continuous
integration tests.
For information about triggering CI builds via @swift-ci, see:
https://github.com/apple/swift/blob/main/docs/ContinuousIntegration.md#swift-ci
Thank you for your contribution to Swift!
-->
The previous algorithm was doing an iterative forward data flow analysis
followed by a reverse data flow analysis. I suspect the history here is that
it was a reverse analysis, and that didn't really work for infinite loops,
and so complexity accumulated.
The new algorithm is quite straightforward and relies on the allocations
being properly jointly post-dominated, just not nested. We simply walk
forward through the blocks in consistent-with-dominance order, maintaining
the stack of active allocations and deferring deallocations that are
improperly nested until we deallocate the allocations above it. The only
real subtlety is that we have to delay walking into dead-end regions until
we've seen all of the edges into them, so that we can know whether we have
a coherent stack state in them. If the state is incoherent, we need to
remove any deallocations of previous allocations because we cannot talk
correctly about what's on top of the stack.
The reason I'm doing this, besides it just being a simpler and hopefully
faster algorithm, is that modeling some of the uses of the async stack
allocator properly requires builtins that cannot just be semantically
reordered. That should be somewhat easier to handle with the new approach,
although really (1) we should not have runtime functions that need this and
(2) we're going to need a conservatively-correct solution that's different
from this anyway because hoisting allocations is *also* limited in its own
way.
I've attached a rather pedantic proof of the correctness of the algorithm.
The thing that concerns me most about the rewritten pass is that it isn't
actually validating joint post-dominance on input, so if you give it bad
input, it might be a little mystifying to debug the verifier failures.
With the feature enabled any function type without an explicit `@concurrent`
is going to be inferred to be `nonisolated(nonsending)`. `@concurrent` should
always be printed for diagnostic and other purposes because the isolation
checking would consider them to be `nonisolated(nonsending)` otherwise, especially
important to code produced by fix-its.
Resolves: rdar://161739470
