Provide member macros with similar information about conformances to
what extension macros receive, allowing member macros to document
which conformances they care about (e.g., Decodable) and then
receiving the list of conformances that aren't already available for
the type in question. For example, a macro such as
@attached(member, conformances: Decodable, Encodable, names:
named(init(from:), encode(to:)))
macro Codable() = ...
Expanded on a type that is not already Decodable/Encodable would be
provided with Decodable and Encodable (via the new
`missingConformancesTo:` argument to the macro implementation) when
the type itself does not conform to those types.
Member macros still cannot produce conformances, so this is likely to
be used in conjunction with extension macros most of the time. The
extension macro declares the conformance, and can also declare any
members that shouldn't be part of the primary type definition---such
as initializers that shouldn't suppress the memberwise initializer. On
the other hand, the member macro will need to define any members that
must be in the primary definition, such as required initializers,
members that must be overridable by subclasses, and stored properties.
Codable synthesis is an example that benefits from member macros with
conformances, because for classes it wants to introduce a required
initializer for decoding and an overridable encode operation, and
these must be members of the nominal type itself. Specifically, the
`Codable` macro above is likely to have two attached member roles:
@attached(member, conformances: Decodable, Encodable, names:
named(init(from:), encode(to:)))
@attached(extension, conformances: Decodable, Encodable, names:
named(init(from:), encode(to:)))
macro Codable() = ...
where the "extension" role is responsible for defining the conformance
(always), and the "member" creates the appropriate members for classes
(`init` vs. `required init`).
Tracked by rdar://112532829.
Replace the `front()` and `back()` accessors on `InheritedTypes` with dedicated
functions for accessing the start and end source locations of the inheritance
clause. NFC.
Wrap the `InheritedEntry` array available on both `ExtensionDecl` and
`TypeDecl` in a new `InheritedTypes` class. This class will provide shared
conveniences for working with inherited type clauses. NFC.
And add a comment explaining why this check is only relevant to protocols, and shouldn't
be copied to other similar-looking isResilient methods on other types.
According to 25376025ae, which introduced the original
`@_originallyDefinedIn` check, this check was necessary to maintain ABI compatibility
when protocol declarations are moved, but in all other cases, we should treat declarations
as resilient when they are defined in other library-evolution-enabled modules, even when
the declaration was originally defined in the current module.
This reverts commit d5b354fd5f. It causes miscompiles when
accessing properties declared with `@_originallyDefinedIn` that are now defined in modules
with library evolution enabled from the module that the property was originally defined in.
Just because the property used to be declared in the current module doesn't mean it can
bypass the stable ABI of the module that the property now belongs to.
It looks like the logic that this PR replaced is also faulty, since `@_originallyDefinedIn`
really oughtn't factor into the resilience computation at any level, but let's unwind one
level of brokenness at a time.
Fixes rdar://113935401.
Cache a bit on `EnumDecl` indicating whether there are any elements that are
unavailable during lowering and then use that bit to decided whether to attempt
optimization for `switch_enum`/`switch_enum_addr` instructions.
The cached values for `hasOnlyCasesWithoutAssociatedValues()` and
`hasPotentiallyUnavailableCaseValue()` are computed in a single pass over the
elements of an `EnumDecl`. However, the pass would return early after finding
an element with an associated value, without checking whether any of the rest
of the elements were potentially unavailable. This made `Comparable` synthesis
succeed for any enum with potentially unavailable elements so long as the first
element in the enum has an associated value.
This is a futile attempt to discourage future use of getType() by
giving it a "scary" name.
We want people to use getInterfaceType() like with the other decl kinds.
The check for "has property wrappers" as part of determining whether the
layout of a variable is exposed to clients can trigger reference
cycles. Push this check later, which eliminates these cycles for types
that aren't frozen/fixed-layout.
This is a hack, not a real fix, but it eliminates the cyclic
references observed in rdar://112079160.
Unwind a temporary workaround we put into the compiler that treated
the escaped identifier "init" as an initializer in the set of names
introduced by a macro. We've addressed the underlying issues.
Fixes rdar://108589649.
As with the initial value of a property that is converted from a stored
property to a computed property by an accessor macro, remove
didSet/willSet. It is the macro's responsibility to incorporate their
code or diagnose them.
Fixes rdar://111101833.
Eliminate the error message
error: global freestanding macros not yet supported in script mode
by implementing name lookup, type checking, and code emission for
freestanding macros. The key problem here is that, in script mode,
it is ambiguous whether a use of a freestanding macro is an expression
or a declaration. We parse as an expression (as we do within a
function body), which then gets wrapped in a top-level code
declaration.
Teach various parts of the compiler to look through a top-level code
declaration wrapping a macro expansion expression that is for a
declaration or code-item macro, e.g., by recording these for global
name lookup and treating their expansions as "auxiliary" declarations.
Fixes rdar://109699501.
stated in the original source.
If an extension macro can introduce protocol conformances, macro expansion
will check which of those protocols already have a stated conformance in the
original source. The protocols that don't will be passed as arguments to
extension macro expansion, indicating to the macro that it should only add
conformances to those protocols.
This basically undoes 3da6fe9c0d, which in hindsight was wrong.
There were no other usages of TypeArrayView anywhere else except for
GenericSignature::getGenericParams(), and it was almost never what
you want, so callers had to convert back and forth to an ArrayRef.
Remove it.
Attribute @_silgen_name is today only allowed to be used on functions, this change allows usage on globals as well. The motivation for that is to be able to "forward declare" globals just like it's today possible to do with functions (for the cases where it's not practical or convenient to use a bridging header).
Separately, this change also adds a @_silgen_name(raw: ...) syntax, which simply avoids mangling the name (by using the \01 name prefix that LLVM uses). The motivation for that is to be able to reference the "magic Darwin linker symbols" that can be used to look up section bounds (in the current dylib/module) -- those symbols don't use the underscore prefix in their mangled names.
Per the clarification during the review thread, all properties with
init accessors (including those that do not initialize any underlying
storage) are part of the memberwise initializer.
Reformatting everything now that we have `llvm` namespaces. I've
separated this from the main commit to help manage merge-conflicts and
for making it a bit easier to read the mega-patch.
This is phase-1 of switching from llvm::Optional to std::optional in the
next rebranch. llvm::Optional was removed from upstream LLVM, so we need
to migrate off rather soon. On Darwin, std::optional, and llvm::Optional
have the same layout, so we don't need to be as concerned about ABI
beyond the name mangling. `llvm::Optional` is only returned from one
function in
```
getStandardTypeSubst(StringRef TypeName,
bool allowConcurrencyManglings);
```
It's the return value, so it should not impact the mangling of the
function, and the layout is the same as `std::optional`, so it should be
mostly okay. This function doesn't appear to have users, and the ABI was
already broken 2 years ago for concurrency and no one seemed to notice
so this should be "okay".
I'm doing the migration incrementally so that folks working on main can
cherry-pick back to the release/5.9 branch. Once 5.9 is done and locked
away, then we can go through and finish the replacement. Since `None`
and `Optional` show up in contexts where they are not `llvm::None` and
`llvm::Optional`, I'm preparing the work now by going through and
removing the namespace unwrapping and making the `llvm` namespace
explicit. This should make it fairly mechanical to go through and
replace llvm::Optional with std::optional, and llvm::None with
std::nullopt. It's also a change that can be brought onto the
release/5.9 with minimal impact. This should be an NFC change.
Macro-generated extensions are hoisted to file scope, because extensions are
not valid in nested scopes. Callers of 'visitAuxiliaryDecls' assume that the
auxiliary decls are in the same decl context as the original, which is clearly
not the case for extensions, and it leads to issues like visiting extension at
the wrong time during SILGen. The extensions are already added to the top-level
decls, so we don't need to visit them as auxiliary decls, and we can type-check
macro-expanded decls at the end of visitation in TypeCheckDeclPrimary.
