This change modifies the dependency scanner to keep track of source locations of each encountered 'import' statement, in order to be able to emit diagnostics with source locations if an import failed to resolve.
- Keep track of each 'import' statement's source buffer, line number, and column number when adding it. The dependency scanner utilizes separate compilation instances, and therefore separate Source Managers for scanning `import` statements of user sources and textual interfaces of Swift dependencies. Since import resolution may happen in the main scanner compilation instance while the `import` itself was found by an interface-scanning sub-instance, we cannot simply hold on to the import's `SourceLoc`.
- Add libSwiftScan API for diagnostics to carry above source locations to clients.
When diagnosing a case where an actor-isolated witness cannot satisfy
a non-isolated requirement, also suggest that the conformance could be
annotated with `@preconcurrency`.
When diagnosing a concurrency-unsafe global or static variable, provide
Fix-Its with specific guidance and advice. This is intended to aid the
workflow for folks enabling strict concurrency checking or Swift 6.
There are up to three Fix-Its attached to a diagnostic about
concurrency-unsafe global/static variables:
* convert 'global' to a 'let' constant to make the shared state
immutable, which replaces `var` with `let`
* restrict 'global' to the main actor if it will only be accessed from the
main thread, which adds `@MainActor`
* unsafely mark %0 as concurrency-safe if all accesses are protected
by an external synchronization mechanism, which adds `nonisolated(unsafe)`
I fretted over two things before deciding on this path:
1. For the second note, the reality is that any global actor will
suffice, but `@MainActor` is orders of magnitude more common than any
other global actor, so "common case convenience" wins over "precise
but less useful.
2. For the third note, `nonisolated(unsafe)` should only be used
sparingly, and surfacing it via Fix-It could cause overuse. However,
developers need to know about it, and this is how we do that. It comes
last in the list of notes (after the better options) and says "unsafe"
in not one but two places.
…for extensions. This change also removes @implementation(CategoryName); you should attach the category name to the @objc attribute instead. And there are small changes to how much checking the compiler will do on an @objc @implementation after the decl checker has discovered a problem with it.
Instance properties of non-sendable types cannot safely be
accessed within deinitializers. Make sure we respect `@preconcurrency`
when diagnosing these.
A few things:
1. Internally except for in the parser and the clang importer, we only represent
'sending'. This means that it will be easy to remove 'transferring' once enough
time has passed.
2. I included a warning that suggested to the user to change 'transferring' ->
'sending'.
3. I duplicated the parsing diagnostics for 'sending' so both will still get
different sets of diagnostics for parsing issues... but anywhere below parsing,
I have just changed 'transferring' to 'sending' since transferring isn't
represented at those lower levels.
4. Since SendingArgsAndResults is always enabled when TransferringArgsAndResults
is enabled (NOTE not vis-a-versa), we know that we can always parse sending. So
we import "transferring" as "sending". This means that even if one marks a
function with "transferring", the compiler will guard it behind a
SendingArgsAndResults -D flag and in the imported header print out sending.
rdar://128216574
This now specifies a category name that’s used in TBDGen, IRGen, and PrintAsClang. There are also now category name conflict diagnostics; these subsume some @implementation diagnostics.
(It turns out there was already a check for @objc(CustomName) to make sure it wasn’t a selector!)
The diagnostic for non-Sendable globa/static `let` properties was checking
for a Sendable conformance without considering `@preconcurrency`. Emit
this diagnostic via a `@preconcurrency`-sensitive path.
Fixes rdar://121889248.
This fixes a compiler crash that happened when emitting a Clang header for a Swift module that declares multiple macros with the same base name and different argument names.
Swift macros are not currently designed to be exposed to C++. This teaches the compiler to explicitly mark them as unavailable in C++.
rdar://117969472 / resolves https://github.com/apple/swift/issues/69656
This PR treats package access level as exportable, preventing
internally imported types from accidentally being declared in
package decl signatures.
Added package-specific cases to ExportabilityReason and
DisallowedOriginKind to track the validity of imported types
at use sites with package access scope. Added tests to cover
variety of use cases.
Resolves rdar://117586046&125050064&124484388&124306642
When swift dependency scanner first finds a binary module for a testable
import, verify if the module is built for enable-testing or not. If not,
keeps searching in case there is a second testable binary module in the
search path.
Previously, the first binary module will always be accepted by scanner
and rely on the importer to provide a good diagnostics. Now the scanner
will emit a warning before continue searching, so user understands why
the binary in the search path is not taken.
This protocol appears in the stdlib as scaffolding for the
`NonescapableTypes` feature, which is still experimental and not gone
through evolution as an approved addition to the stdlib.
Rather than delete it from the stdlib, because it needs to still remain
to support that feature work, gate references to it behind a feature
flag.
Additionally, prevent documentation from seeing this declaration.
rdar://126705184
Access-level on imports limit where decls from the target module can
be referenced. This is reported by the typical error about and a note
on the import. However, when using an IDE and editing a large file,
the note on the import is easy to miss. Address this by duplicating
the information on the error line as well so it's never out of the
current viewport.
rdar://119438201
Adoption InternalImportsByDefault provides a safe access-level by default
to imports, as such ambiguities are not a risk and showing this warning is
superflous. When this warning is shown, make sure we note this alternative.
Report uses of `@_implementationOnly` in resilient modules as deprecated.
With a fixit to replace it with `internal` or delete it when imports
are internal by default.
Uses of `@_implementationOnly` in non-resilient modules is already reported
as being unsafe.
Package decls were made to be resilient at the definition
site by default. By allowing the attributes to be applied
to package decls, we can enable non-resilient access.
Resolves rdar://125169361
