Type check user-defined macros plugins with user-provided type signatures.
Also, load plugin libraries with `RTLD_LOCAL` instead of `RTLD_GLOBAL` to prevent symbol collision between plugins. `llvm::sys::DynamicLibrary` only supports `RTLD_GLOBAL` so we use the plain `dlopen` instead. This does not work on Windows and needs to be fixed.
Friend PR: apple/swift-syntax#1042
Allow user-defined macros to be loaded from dynamic libraries and evaluated.
- Introduce a _CompilerPluginSupport module installed into the toolchain. Its `_CompilerPlugin` protocol acts as a stable interface between the compiler and user-defined macros.
- Introduce a `-load-plugin-library <path>` attribute which allows users to specify dynamic libraries to be loaded into the compiler.
A macro library must declare a public top-level computed property `public var allMacros: [Any.Type]` and be compiled to a dynamic library. The compiler will call the getter of this property to obtain and register all macros.
Known issues:
- We current do not have a way to strip out unnecessary symbols from the plugin dylib, i.e. produce a plugin library that does not contain SwiftSyntax symbols that will collide with the compiler itself.
- `MacroExpansionExpr`'s type is hard-coded as `(Int, String)`. It should instead be specified by the macro via protocol requirements such as `signature` and `genericSignature`. We need more protocol requirements in `_CompilerPlugin` to handle this.
- `dlopen` is not secure and is only for prototyping use here.
Friend PR: apple/swift-syntax#1022
During prechecking, postfix '...' expressions are rewritten to pack
expansion expressions if the operand contains pack references. References
to packs are replaced with opaque values, and the pack expansion stores
the opaque value bindings to decl refs.
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`.
Update `applyPropertyWrapperToParameter` to set types to projected
and wrapped values and allow `TypeVariableRefFinder` to skip decls
with implicit property wrappers that are not yet resolved.
Reference to `$geneator.next` in for-in loop context needs to be
treated as a reference to a witness of `IteratorProtocol#next`
requirement, otherwise it could lead to problems with retroactive
conformances.
Replace the use of bool and pointer returns for
`walkToXXXPre`/`walkToXXXPost`, and instead use
explicit actions such as `Action::Continue(E)`,
`Action::SkipChildren(E)`, and `Action::Stop()`.
There are also conditional variants, e.g
`Action::SkipChildrenIf`, `Action::VisitChildrenIf`,
and `Action::StopIf`.
There is still more work that can be done here, in
particular:
- SourceEntityWalker still needs to be migrated.
- Some uses of `return false` in pre-visitation
methods can likely now be replaced by
`Action::Stop`.
- We still use bool and pointer returns internally
within the ASTWalker traversal, which could likely
be improved.
But I'm leaving those as future work for now as
this patch is already large enough.
Introduce the compiler directive `#_hasSymbol` which will be used to detect whether weakly linked symbols are present at runtime. It is intended for use in combination with `@_weakLinked import` or `-weak-link-at-target`.
```
if #_hasSymbol(foo(_:)) {
foo(42)
}
```
Parsing only; SILGen is coming in a later commit.
Resolves rdar://99342017
In cases like `.<name>(_)`, the `_` sub-pattern should not assume
locator of the parent paren, just like it doesn't in case of tuple
i.e. `.<name>(_, ...)` where each element gets a `PatternMatch(<elt>)`
locator.
`_` pattern doesn't have a type, it's always contextual, so let's
allow it to assume a type of initializer expression instead of
creating a new type variable. This helps to makes sure that initializer
would never get a placeholder type from `_` pattern it's associated
with.
In cases like `case .test(_)` it might not be possible to
establish a type of `_` and hole cannot be propagated to
it from context if condition of switch is incorrect, so
`_` just like a named pattern should be allowed to become
a hole.
Resolves: rdar://96997534
Instead of failing constraint generation by returning `nullptr` for an `ErrorExpr` or returning a null type when a type fails to be resolved, return a fresh type variable. This allows the constraint solver to continue further and produce more meaningful diagnostics.
Most importantly, it allows us to produce a solution where previously constraint generation for a syntactic element had failed, which is required to type check multi-statement closures in result builders inside the constraint system.
Emulate previous `for-in` type-checking behavior where sequence
was type-checked separately from `.next()` call which, in turn,
was injected only during SIL generation.
Current approach to generate an implicit variable for `$generator`
and use it as a base to `.next()` call didn't account for the fact
that it allows the solver to rank result of `<sequence>.makeIterator()`
together with result of `next()`. This is logically incorrect because
`<sequence>.makeIterator()` represents initializer of `$generator`
which is separate from `$generator.next()` expression albeit type-checked
together.
Resolves: https://github.com/apple/swift/issues/59522
Don't so would disconnect $generator from `.next()` call which
have to be solved together because they sometimes depend on the
for-in pattern to infer the element type.
Instead of asking SILGen to build calls to `makeIterator` and
`$generator.next()`, let's synthesize and type-check them
together with the rest of for-in preamble. This greatly simplifies
interaction between Sema and SILGen for for-in statements.
