This change applies SwiftAttr attributes as soon as possible after creating an instance of a Decl, rather than waiting until the declaration is "finished". That makes sure the attributes can influence the declaration very early in its lifecycle, and in particular, before its conformance table is initialized.
Mostly NFC in this commit (other than affecting the order that attributes are printed in), but necessary for future changes in this PR.
llvm-project updated `hashExtension` in
655bea4226b401a11164f99c6344e38d8742b8e4 to use a `HashBuilder` rather
than `hash_code`. Update use in ClangImporter.
For clang symbols marked with SPI_AVAILABLE, we add SPIAccessControlAttr to them so they will be
considered as SPIs in the AST. To be able to use all these symbols, we also add an implicit SPI import
statement for all clang modules. All clang SPIs belong to the same SPI group named "OBJC_DEFUALT_SPI_GROUP" because clang
currently doesn't support custom SPI group.
rdar://73902734
Previously a namespace declaration was imported along with all of its redeclarations, and their members were added to a single Swift extension. This was problematic when a single namespace is declared in multiple modules – the extension belonged to only one of them.
For an example of this, try printing a module interface for `std.string`/`std.iosfwd` – it will be empty, even though the declarations from those modules are actually imported into Swift correctly.
This change makes sure that when we're importing different redeclarations of the same namespace, we're adding them as separate extensions to appropriate modules.
If a swift_name attribute’s context referred to the same declaration it was attached to, or a different declaration whose own swift_name referred to the current one, we would recurse infinitely and eventually overflow the stack. This commit makes us instead detect the cycle, diagnose it with a warning, and drop the affected declaration.
Fixes rdar://79370809.
Constructor call of ModuleFileExtension has been updated to allow the
toolchain to build.
Previously this constructor call was passed a bogus value as a
workaround in response to clang change https://reviews.llvm.org/D96155.
The workaround was added in commit 2dfe3551a3.
Due to clang update https://reviews.llvm.org/D97702, ModuleFileExtension
no longer requires constructor parameters.
I was unable to verify this fix works due to other problems in next
branch.
either as an `async` or `async throws` property, by marking it
with swift_async_name("getter:PROPERTY_NAME()") where `PROPERTY_NAME`
will be the name of the property it will be imported as.
This is in lieu of being imported as an async method. It's still
imported as an `@objc` method as well.
Introduce the notion of "unsafe" @Sendable parameters, indicated by the
hidden @_unsafeSendable parameter attribute. Closure arguments to such
parameters are treated as @Sendable within code that has already
adopted concurrency, but are otherwise enert, allowing them to be
applied to existing concurrency-related APIs to smooth the transition
path to concurrency.
Additionally, introduce the notion of an "unsafe" @MainActor closure,
for cases where we have determined that the closure will execute on
the main actor but it (also) isn't part of the type system.
Pattern-match uses of the Dispatch library's DispatchQueue to infer
both kinds of "unsafe" as appropriate, especially (e.g.) matching the pattern
DispatchQueue.main.async { ... }
to treat the closure as unsafe @Sendable and @MainActor, allowing such
existing code to better integrate with concurrency.
Implements rdar://75988966.
The diagnostics system doesn't allow a diagnostic to be emitted while
another diagnostic is in flight. Doing so will cause an assertion in
the diagnostics machinery.
There's a longstanding cycle here when diagnostics emission
pretty-prints declarations that are imported from a Clang module, and
the Clang Importer emits a diagnostic. Squash this cycle forcefully,
dropping the diagnostic that the Clang importer would emit.
Add a temporary workaround for https://reviews.llvm.org/D96155, which
added a sealed RTTI hierarchy to ModuleFileExtension. We pass a bogus
value for now. A better solution will arrive in D97702.
This change adds support for calling `operator()` from Swift code.
As the C++ interop manifesto describes, `operator()` is imported into Swift as `callAsFunction`.
A change in the new clang branch seems to have caused it to start applying SwiftNameAttrs to forward declarations. We have apparently always tried to add these forward declarations to the lookup tables in PCH files, but never diagnosed the resulting failures because they did not have SwiftNameAttrs. Now they do, so we started emitting incorrect warnings.
We *probably* don’t need to process these at all, but there’s a risk of unintended behavior changes from that; instead, this commit takes a conservative approach and simply suppresses the warnings like we always have.
Fixes rdar://74710976.
Our name lookup rules for the resolution of custom attributes don't
allow for them to find MainActor within the _Concurrency library.
Therefore, hardcode @MainActor to map to _Concurrency.MainActor.
While here, make sure we drop concurrency-specific attributes that
show up in Clang attributes when we aren't in concurrency mode.
The Clang swift_attr attribute allows C code to describe, via a Clang
attribute, the Swift attributes that should be applied to the given
declaration. When an
__attribute__((__swift_attr__("@tribute")))
occurs on a Clang declaration, parse the attribute within the string
literal as a Swift attribute, then attach that to the imported Swift
declaration.
Fixes rdar://70146633.
