llvm::Optional had a constructor that took a const l-value
reference, but std::optional does not, resulting in build failures when
returning bit-fields in optionals. Casting the bit-field to the
appropriate type fixes this.
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.
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.
Previously only stored properties could be initializable but with
introduction of init accessors computed properties gained an ability
to specify initialzer expression and participation in memberwise
initialization for structs.
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.
The `hasStorage()` computation is used in many places to determine the
signatures of other declarations. It currently needs to expand accessor
macros, which causes a number of cyclic references. Provide a
simplified request to determine `hasStorage` without expanding or
resolving macros, breaking a common pattern of cycles when using
macros.
Fixes rdar://109668383.
Expand macros in the specified source file syntactically (without any
module imports, nor typechecking).
Request would look like:
```
{
key.compilerargs: [...]
key.sourcefile: <file name>
key.sourcetext: <source text> (optional)
key.expansions: [<expansion specifier>...]
}
```
`key.compilerargs` are used for getting plugins search paths. If
`key.sourcetext` is not specified, it's loaded from the file system.
Each `<expansion sepecifier>` is
```
{
key.offset: <offset>
key.modulename: <plugin module name>
key.typename: <macro typename>
key.macro_roles: [<macro role UID>...]
}
```
Clients have to provide the module and type names because that's
semantic.
Response is a `CategorizedEdits` just like (semantic) "ExpandMacro"
refactoring. But without `key.buffer_name`. Nested expnasions are not
supported at this point.
Some places want to do in-order walks of MacroExpansionDecls, but still
visit auxiliary declarations. Rather than force them to specifically
filter out declarations from the MacroExpansionDecl, add a parameter to
visitAuxiliaryDecls to skip them.
'MacroExpansionDecl' and 'MacroExpansionExpr' have many common methods.
Introduce a common base class 'FreestandingMacroExpansion' that holds
'MacroExpansionInfo'.
Factor out common expansion logic to 'evaluateFreestandingMacro'
function that resembles 'evaluateAttachedMacro'.
We were not type checking the default argument initializer because `MacroDecl` is not an `AbstractFucntionDecl`. Add `MacroDecl` to the list of nodes we know how to get parameters from.
rdar://108163564
When an accessor macro adds a non-observing accessor to a property, it
subsumes the initializer. We had previously modeled this as removing
the initializer, but doing so means that the initializer could not be
used for type inference and was lost in the AST.
Explicitly mark the initializer as "subsumed" here, and be more
careful when querying the initializer to distinguish between "the
initializer that was written" and "the initializer that will execute"
in more places. This distinction already existed at the
pattern-binding level, but not at the variable-declaration level.
This is the proper fix for the circular reference issue described in
rdar://108565923 (test case in the prior commit).
It doesn't seem like there's any client that's
actually taking advantage of setting it to `false`,
and its default value of `false` is more likely
than not going to cause clients to accidentally
miss comments that they may want. In fact, this
was exactly the case for code completion's brief
field. Finally, the parameter wasn't even
consistently applied, as we would attempt to
deserialize swiftdoc comments even if it were
`false`.
If a parameter is marked consuming and its type is Copyable, that
parameter has eager-move semantics. Apply that attribute to the
SILFunctionArgument corresponding to the parameter.
rdar://108385761
inside closures while type checking a macro expansion.
PreCheckExpr, ConstraintGenerator, and other walkers do not walk into macro
expansions. However, the implementation of this macro walking behavior in
ASTWalker would skip any declaration that appears inside any macro expansion
buffer. This is incorrect for cases where the parent is in the same macro
expansion buffer, because the local declaration is not inside a new macro
expansion. This caused bogus errors when type checking expanded macro expressions
containing closures with local declarations, because pre-check and constraint
generation mistakenly skipped local pattern bindings.
Eliminate a source of cyclic dependencies by not expanding macros when
we are resolving macro arguments within a type or extension context.
This extends the scheme introduced for module-scope lookup to also
apply to lookup within types.
Add a private discriminator to the mangling of an outermost-private `MacroExpansionDecl` so that declaration macros in different files won't have colliding macro expansion buffer names.
rdar://107462515
Sometimes we build a `MacroExpansionDecl` from a `MacroExpansionExpr`.
Sometimes we do it the other way. In both cases, we risk the two
copies of must-by-shared data (macro arguments, resolved macro
reference, etc.) getting out-of-sync.
Instead, share the storage between the two representations when we
create one from the other, so that they cannot get out-of-sync. This
allows us to eliminate the extremely-dodgy `cacheOutput` call earlier.
