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.
If we have a C++ record decl that's invalid (because of a deleted
destructor or copy constructor), bail before we import any of its
members or cache the decl. This way, we don't accidentally import any
"nested" decls.
Extend the parsing of custom attributes to apply to types. Improve the
lookahead for the arguments so we don't arbitrarily consume the parameter
list of a function type as an attribute argument, or consume a tuple type
as the attribute argument.
Doesn't actually change behavior, because after parsing the custom
attribute on a type, we reject it as an unknown attribute.
While it is very convenient to default the ExtInfo state when creating
new function types, it also make the intent unclear to those looking to
extend ExtInfo state. For example, did a given call site intend to have
the default ExtInfo state or does it just happen to work? This matters a
lot because function types are regularly unpacked and rebuilt and it's
really easy to accidentally drop ExtInfo state.
By changing the ExtInfo state to an optional, we can track when it is
actually needed.
Fail correctly if we can't import a shadow decl properly. We can
probably support this in the future, but right now, it's more important
that we don't crash while importing.
This change adds support for calling `operator()` from Swift code.
As the C++ interop manifesto describes, `operator()` is imported into Swift as `callAsFunction`.
Allow us to tag declarations that are meant to be in a global actor, but
for which we don't yet want to enforce everything. This will be used for
better staging-in of global actor annotations, but for now it's a fancy
way to document @actorIndependent(unsafe).
Stages in the syntax for rdar://74241687 without really implementing it.
Lazily instantiate class template members. This means we no longer
reject some programs that clang accepts, such as the following:
```
template<class T> struct Foo { void fail(T value) { value.fail(); } };
using Bar = Foo<int>;
```
The above program will not error so long as `Bar::fail` isn't called.
(Previously, we'd fail to import `Bar`.)
If a template specialization is more than 8 types deep, bail.
In future we could make this number (much) greater than 8 but first
we'll need to somehow make instantiating these types much fater.
Currently, I think there is some exponential type behavior happening so
this is super slow.
C++ namespaces are module-independent, but enums are owned by their module's in Swift. So, to prevent declaring two enums with the same name, this patch implements a new approach to namespaces: enums with extensions.
Here's an example:
```
// Module A
namespace N { void test1(); }
// Module B
namespace N { void test2(); }
// __ObjC module
enum N { }
// Swift module A
extension N { func test1() }
// Swift module B
extension N { func test1() }
```
Thanks to @gribozavr for the great idea.
Rather than skipping non-definitions, we should just check whether we've
already seen this decl. This not only fixes the specific problem with
class templates but also is a more general fix for other sub decls.
The Clang importer had some logic to suppress the import of a property that
had the same name as a method with no parameters. This logic
inadvertently meant that an async import of a completion-handler method
could prevent a (non-async) property of the same name to not be
imported, breaking existing code. In such cases, don't suppress the
property import.
Fixes rdar://73326019.
This patch softly updates the spelling of actors from `actor class` to
`actor`. We still accept using `actor` as a modifying attribute of
class, but emit a warning and fix-it to make the change.
One of the challenges that makes this messier is that the modifier list
can be in any order. e.g, `public actor class Foo {}` is the same as
`actor public class Foo {}`.
Classes have been updated to include whether they were explicitly
declared as an actor. This change updates the swiftmodule serialization
version number to 0.591. The additional bit only gets set of the class
declaration was declared as an actor, not if the actor was applied as an
attribute. This allows us to correctly emit `actor class` vs `actor`
emitting the code back out.
This PR makes it possible to instantiate C++ class templates from Swift. Given a C++ header:
```c++
// C++ module `ClassTemplates`
template<class T>
struct MagicWrapper {
T t;
};
struct MagicNumber {};
```
it is now possible to write in Swift:
```swift
import ClassTemplates
func x() -> MagicWrapper<MagicNumber> {
return MagicWrapper<MagicNumber>()
}
```
This is achieved by importing C++ class templates as generic structs, and then when Swift type checker calls `applyGenericArguments` we detect when the generic struct is backed by the C++ class template and call Clang to instantiate the template. In order to make it possible to put class instantiations such as `MagicWrapper<MagicNumber>` into Swift signatures, we have created a new field in `StructDecl` named `TemplateInstantiationType` where the typechecker stores the `BoundGenericType` which we serialize. Deserializer then notices that the `BoundGenericType` is actually a C++ class template and performs the instantiation logic.
Depends on https://github.com/apple/swift/pull/33420.
Progress towards https://bugs.swift.org/browse/SR-13261.
Fixes https://bugs.swift.org/browse/SR-13775.
Co-authored-by: Dmitri Gribenko <gribozavr@gmail.com>
Co-authored-by: Rosica Dejanovska <rosica@google.com>
