If we have a custom attribute on a type that does a qualified lookup
into the same type, we need to be able to expand member attribute
macros for that type. As such, the check to see if we already have
a nominal for the attribute would hit a cycle. Limit this check such
that it only applies to local vars, which is the only case where it
actually matters.
rdar://163961797
This ports clang's test suite for update-verify-tests from C to Swift,
and adjusts update-verify-tests as needed. The main differences are the
Swift -verify output format being quite different, as well as Swift's
'-verify-additional-prefix foo' working differently than clang's
'-verify=foo'.
This script is used to automatically update test cases using -verify in
clang's test suite. Swift also has a similar -verify test functionality,
and while it can automatically fix some of them using -verify-apply-all,
this functionality only updates existing checks - it doesn't add or
remove any, and it doesn't handle newer and more complex things like
expected-expansion. Handling that type of complexity feels out of scope
to embed in the compiler, so let's copy clang's approach.
This commit adds this script as is from clang. It doesn't work at all
for Swift in its current form, as the output from Swift's -verify is
formatted differently than in clang. This will be fixed in subsequent
commits.
This could have been done by adapting the script as-is in the
llvm-project repository (since it only exists in the Swift fork, not
upstream), but tests using swift-frontend would have to reside in the
swift repo, and modifying a script in one repo with tests in a different
repo sounds like a recipe for endless CI issues.
`os.path.dirname` removes the last path component of a path. If there was a git failure in `~/src/swift`, this means that we show `~/src` as the repo name, which isn’t very helpful. Use `os.path.basename`, which returns the last path component, ie. `swift`.
Clang is helpfully telling us that one of the base types is
inaccessible, except we don't really care about that because we are only
using this type for testing other diagnostics. That warning is getting
caught by the newly comprehensive swiftc diagnostic verifier, so we
suppress it with a Clang pragma.
rdar://163875420
Swift has not had user-defined conversions since before Swift 1.0.
Remove the running example from the discussion of locators. This
probably makes the explanation too opaque, but the old explanation
was useless because it was out of date.
I'll add a proper example later.
Don't consider implicitly exposed memory layouts when checking for
usable from inline correctness. That check applies only to memory
layouts marked as exposed explicitly. Consider the implict state only at
the general availability checking.
In non-library-evolution mode, gated behind the CheckImplementationOnly
feature flag, report references to structs marked with
`@_implementationOnly` from a fragile context. Preventing references
from inlinable functions and structs not marked `@_implementationOnly`.
In non-library-evolution mode, gated behind the CheckImplementationOnly
feature flag, consider structs to be a fragile use site by default,
unless marked `@_implementationOnly`. This prevents them to refer to
restricted imports like implementation-only.
- 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
