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.
This source location will be used to determine whether to add a name lookup
option to exclude macro expansions when the name lookup request is constructed.
Currently, the source location argument is unused.
Some notes:
1. I put in both a swiftpm like test case and a library evolution test case. I
also updated the moveonly_deinit serialization swift test to show that we
actually serialize the deinit.
2. I changed when we emit the deinit table to only be when we have a type with
an actual value type destructor. Notably this doesn't include classes today so
as a side-effect, we no longer attempt to devirtualize moveonly class deinits.
This doesn't affect anything we are trying to actually do since we do not
support noncopyable classes today. With that in mind, I changed one test that
was showing that deinit devirtualization worked to use a struct with deinit
instead of a class.
rdar://109679168
When expanding a conformance macro, the generated extension decls are added to
the TopLevelDecls vector of the synthesized file unit to expose them to
sf->getSynthesizedFile()->getTopLevelDecls(). There are two problems with this:
1. These decls are also visited via visitAuxiliaryDecls() for the purpose of
type checking. This causes problems in code generation because the extensions
are visited separately, and because SIL and IRGen assume nested auxiliary decls
are members.
2. SILGen only emits top-level decls directly from the source file rather than its
synthesized file. Auxiliary decls are visited here, but this doesn't work for
nested conformance macros because the attached-to decl is not at the top-level,
so macro-generated conformances for nested types never emit their descriptor.
To fix this in the short term, visit top-level decls in the synthesized file that are
generated by conformance macros, and skip auxiliary extension decls when emitting type
members. This fix is narrowly scoped to only impact macros, but in the future this
warrants a more structural fix to better handle top-level decls in the synthesized file.
Previously, the location used for functions corresponding to @main was
just RegularLocation::getModuleLocation(). Make that more specific by
using the annotated type's location instead.
rdar://79508092
Allow freestanding macros to be used at top-level.
- Parse top-level `#…` as `MacroExpansionDecl` when we are not in scripting mode.
- Add macro expansion decls to the source lookup cache with name-driven lazy expansion. Not supporting arbitrary name yet.
- Experimental support for script mode and brace-level declaration macro expansions: When type-checking a `MacroExpansionExpr`, assign it a substitute `MacroExpansionDecl` if the macro reference resolves to a declaration macro. This doesn’t work quite fully yet and will be enabled in a future fix.
Always use `Decl::visitAuxiliaryDecls` to visit decls produced by macros, including peer macros and declaration macros. Use name-driven expansion for peer macros. Remove `MacroExpansionDecl::getRewritten()`.
Also make `ExpandMacroExpansionDeclRequest` cache the buffer ID (similar to other macros) instead of an array of decls.
Previously, typechecking and SILGen would treat a function body as fragile as long as the declaration had a `@backDeployed` attribute, regardless of the platform specified by the attribute. This was overly conservative since back deployed functions are only emitted into the client on specific platforms. Now a `@backDeployed` function can reference non-`public` declarations on the platforms it is resilient on:
```
@backDeployed(before: iOS 15)
public func foo() {
#if os(iOS)
// Fragile; this code may be emitted into the client.
#else
// Resilient; this code won't ever be exposed to clients.
#endif
}
```
Resolves rdar://105298520
Global peer macro expansions are not injected into the AST. Instead, they
are visited as "auxiliary declarations" when needed, such as in the decl
checker and during SILGen. This is the same mechanism used for local property
wrappers and local lazy variables.
Add support for freestanding declaration macros.
- Parse `@declaration` attribute.
- Type check and expand `MacroExpansionDecl`.
Known issues:
- Generic macros are not yet handled.
- Expansion does not work when the parent decl context is `BraceStmt`. Need to parse freestanding declaration macro expansions in `BraceStmt` as `MacroExpansionDecl`, and add expanded decls to name lookup.
Single expression is not going to cut it in this case because attribute
and attached declaration could have different availability, so we need
to use `if #available` to guard attribute instantiation and return `nil`
in cases where types are not available.
A new `RuntimeAttributeGenerator` is used to reference runtime
attribute generator functions synthesized by SILGen.
`#function` magic literal points to the declaration that declaration
attribute is attached to.
Each entry relates an attribute declaration to a list of all
declarations it's associated with together with a generator
function to acquire instance of the attribute value.
This attribute indicates that the given SILFunction has to be
added to "accessible functions" section and could be looked up
at runtime using a special API.
If the emission of a function is delayed via `emitOrDelayFunction()`, then the function is recorded on a list of delayed functions. If the delayed function is later referenced, then the function moves from the delayed list to the "forced" list which will cause it to actually be emitted later. The implementation of `emitOrDelayFunction()` had a bug when called twice for the same delayable function - it would emit that function prematurely if the function moved to the forced list between the two invocations. Later, during forced function emission a multiple definitions of symbol diagnostic would be emitted since the function was not empty.
This issue could be triggered by `@_backDeploy` functions that have auxilary delayable helper functions (e.g. defer blocks). SILGen visits `@_backDeploy` functions twice (once for the copy of the function emitted into the client and once for the resilient copy of the function) so `emitOrDelayFunction()` is called twice for each of the helper functions and the helper functions could become referenced between the two calls.
The fix is to check for an existing entry in the forced functions list before delaying or emitting a delayable function.
Resolves rdar://102909684
Although the declaration of macros doesn't appear in Swift source code
that uses macros, they still operate as declarations within the
language. Rework `Macro` as `MacroDecl`, a generic value declaration,
which appropriate models its place in the language.
The vast majority of this change is in extending all of the various
switches on declaration kinds to account for macros.
Introduce `MacroExpansionExpr` and `MacroExpansionDecl` and plumb it through. Parse them in roughly the same way we parse `ObjectLiteralExpr`.
The syntax is gated under `-enable-experimental-feature Macros`.
Instead of creating and destroying a SILProfiler
per TopLevelCodeDecl, setup a single profiler
for the top-level entry point function, and visit
all the TopLevelCodeDecls when mapping regions.
Use a main entry-point instead of a null
SILDeclRef. Eventually we'll want to unify the
emission here such that we visit all the
TopLevelDecls in one shot (and just use a single
profiler), but for now we can just hand the
SILProfiler the expected SILDeclRef.
Previously we would delay the emission of
lazy variable getters and stored property
initializers for property wrapper backing storage.
This could lead to their definitions being dropped
if unused, meaning that we wouldn't run the
mandatory diagnostics passes over them.
Fix the logic such that we consider such cases as
having user-written code, and account for a couple
of cases where we can delay emission where we
didn't previously. There are more cases we can
handle here, but I'm leaving that as future work
for now, as `emitOrDelayFunction` is currently
only used for a handful of SILDeclRef kinds.
This is a source breaking change, but only for
invalid (albeit unused) code.
rdar://99962285
Previously we were creating a SILProfiler for
such functions, but weren't actually emitting the
increment, leading to missed coverage.
Part of the fix for rdar://99931619
Specifically, we get an additional table like thing called sil_moveonlydeinit. It looks as follows:
sil_moveonlydeinit TYPE {
@FUNC_NAME
}
It always has a single entry.
Even though with this change we emit the deinit, it isn't used yet since we
still need to implement the move only deinit table/teach the checker how to call
these/teach IRGen how to call this from the destroying value witness.
