It is invalid to reference an internal setter from a fragile function
regardless of whether the storage is unavailable. The swiftinterface generated
for this code would not typecheck since the setter is not known to exist
outside the module.
Use the `%target-swift-5.1-abi-triple` substitution to compile the tests for
deployment to the minimum OS versions required for use of _Concurrency APIs,
instead of disabling availability checking.
Previously we would only call this in the delayed
application logic, which is currently run for
multi-statement closures. I'm planning on
removing that code path, which uncovered this
issue.
- Don't attempt to insert fixes if there are restrictions present, they'd inform the failures.
Inserting fixes too early doesn't help the solver because restriction matching logic would
record the same fixes.
- Adjust impact of the fixes.
Optional conversions shouldn't impact the score in any way because
they are not the source of the issue.
- Look through one level of optional when failure is related to optional injection.
The diagnostic is going to be about underlying type, so there is no reason to print
optional on right-hand side.
Add specific deployment target versions to some tests that need to test
10.x-specific behaviours and are currently depending on the default
deployment target.
Certain tests were only checking either the stable or unstable ABI
depending on the platform the test was running. In those cases I doubled
up the checks so that we would test both cases on platforms that
supported it. This might use a bit of extra time on targets that only
support the stable ABI, but it seemed worth it for the additional
coverage in CI.
For the most part, the differences between the diagnostics introduced
by the C++ implementation and the new SwiftIfConfig implementation are
cosmetic, so these are only wording changes.
The one major difference is that we've dropped the warnings about
potential typos in os/arch checks. For example, if one writes:
#if os(bisionos)
// ...
#endif
The C++ implementation will produce a warning "unknown operating system
for build configuration 'os'" with a note asking "did you mean
'visionOS'"? These warnings rely on a static list of known operating
systems and architectures, which is somewhat unfortunate: the whole
point of these checks is that the Swift you're dealing with might not
have support for those operating systems/architectures, so while these
warnings can be helpful in a few cases, they also cause false
positives when porting. Therefore, I chose not to bring them forward.
Extending a protocol cannot introduce new conformances to other protocols, so
skip checking for associated conformances to public protocols when diagnosing
required availability on such an extension.
Resolves rdar://133873836.
10.50 was once greater than any real macOS version, but now it compares
less than real released versions, which makes these tests depend on the
deployment target unnecessarily. Update these tests to use even larger
numbers to hopefully keep them independent a little longer.
For macOS >= 11 the fixit for narrowing an availability check rather
than adding a new one should fire if the major version is the same, like
on other platforms.
When the type checker noticed that a declaration with application extension
availability markup was used somewhere that it would be potentially unavailable
at runtime, the fix-it emitted by the compiler would check for the application
extension platform's availability:
```
if #available(macOSApplicationExtension 12, *) {
// Use potentially unavailable declarations
}
```
This runtime check won't work. The fix-it should just suggest checking the
availability of the base, non-extension platform instead.
Resolves rdar://125860317.
In this PR i worked on replacing the word accessor in diagnostics with more user-facing terminologies like setter, getter, didSet Observer, and members based on the context of the message.
in some messages i didn't need to pass DescriptiveDeclKind instead i just changed the text copy itself.
i also updated tests, so you might find it easier to check my changes this way.
Please let me know if there's something i should've done in a better way, and request changes if needed. !
i can squash my commits after reviewing getting the PR Reviewed, just to make it easier to be checked commit by commit
Resolves#55887
Some editors use diagnostics from SourceKit to replace build issues. This causes issues if the diagnostics from SourceKit are formatted differently than the build issues. Make sure they are rendered the same way, removing most uses of `DiagnosticsEditorMode`.
To do so, always emit the `add stubs for conformance` note (which previously was only emitted in editor mode) and remove all `; add <something>` suffixes from notes that state which requirements are missing.
rdar://129283608
As much as possible, we should avoid using `REQUIRES: maccatalyst_support`
since tests restricted this way are not run in PR tests. Many tests that
exercise macCatalyst behaviors can be run in a macOS configuration, without
full macCatalyst standard library support.
Also, adopt `%target-cpu` lit substitution where appropriate to avoid needless
standard library module rebuilds when running tests locally.
Attempting to bypass the compiler and access runtime functions directly has
a long history of breaking in hard-to-predict ways, and there's usually a better
way. Put up a warning to try to flush out misuses of runtime functions to see
if we can turn this into an error.
The changes to support `& Sendable` composition with key path
types adjusted `buildKeyPathDynamicMemberArgExpr` to support
that but the use-site erroneously still cast index type or
`BoundGenericType` as before.
Resolves: https://github.com/swiftlang/swift/issues/75244
Resolves: rdar://131768785
We were previously checking the optional type,
which would never say that parens were needed.
Unwrap the type before checking, ensuring we
correctly handle e.g protocol compositions.
