UnresolvedSpecializeExpr.
The eager generic argument matching code in CSGen for unresolved
specializations was incorrect because it didn't account for parameter
packs. Fortunately, a constraint to delay explicit generic argument
matching already exists for macros. Use it here.
'load-plugin-library', 'load-plugin-executable', '-plugin-path' and
'-external-plugin-path' should be searched in the order they are
specified in the arguments.
Previously, for example '-plugin-path' used to precede
'-external-plugin-path' regardless of the position in the arguments.
stripping PackType out of diagnostic arguments.
There are places in the type printing code that assume the substitution for a
type parameter pack is always a pack, and violating that invariant will crash
the compiler. We also never want to print 'Pack{...}' in diagnostics anyway,
so the print option is a better approach and fixes a few existing tests that still
contained 'Pack{...}' in error messages.
@objcImpl extensions aren’t allowed to declare new conformances; instead, they should either be declared in the header or in an ordinary extensions. (If they were permitted, they’d be ignored.)
Fixes rdar://110669366.
Skip stored properties that are initialized via init accessors and
emit parameters/initializations in field order which allows us to
cover more use-cases.
If some property is initializable by one than one init accessor
let's not sythesize a memberwise initializer in that case because
it's ambiguous what is the best init accessor to use.
If init accessor initialize the same properties, let's emit them
in sequence and emit `destroy_addr` in-between to make sure that
there is no double initialization.
Only properties that are listed in 'initializes' and 'accesses'
attributes could be referenced within init accessor. Detect any
and all invalid member references in the solver.
Instead of diagnosing in CSApply, let's create a
fix and diagnose in the solver instead.
Additionally, make sure we assign ErrorTypes to
any VarDecls bound by the invalid pattern, which
fixes a crash.
rdar://110638279
If generic parameter gets opened during regular solving it cannot
be bound to a hole, that can only happen in diagnostic mode, so
let's not even try. Doing so also makes sure that there are no
inference side-effects related to holes because bindings are ranked
based on their attributes.
When an `OpaqueTypeDecl` is constructed, the access level attributes of the
decl that names the opaque type were copied on to it. However, the
`@usableFromInline` attribute is not permitted on every decl, so it does not
get copied. This in turn causes access level computations for opaque types to
fail to take `@usableFromInline` into account and that results in the emitted
symbol getting the wrong linkage during IRGen. The fix is to make access level
computations take this quirk of opaque types into account directly (like they
already to for several other kinds of decls), instead of relying on copying of
attributes.
Resolves rdar://110544170
Apply the same logic that we apply to other
conjunction elements, to make sure that e.g
property wrapper projected values work correctly.
rdar://110649179
Previously we would skip over ExprPatterns, but
we need to ensure that we walk them, as they may
have interesting variable references that the
closure needs to be connected to the type
variables for.
rdar://110617471
namespace.
This moves the `isInMacroArgument` predicate and `lookupMacros` into `namelookup`.
ASTScope still encapsulates the scope tree and contains the operation to lookup
the enclosing macro scope, which then invokes a callback to determine whether a
potential macro scope is indeed a macro, because answering this question requires
name lookup.
names at global scope.
Freestanding and peer macros applied at top-level scope cannot introduce
arbitrary names. Introducing arbitrary names means that any lookup
into this scope must expand the macro. This is a problem, because
resolving the macro can invoke type checking other declarations, e.g.
anything that the macro arguments depend on. If _anything_ the macro
depends on performs name unqualified name lookup, e.g. type resolution,
we'll get circularity errors. It's better to prevent this by banning
these macros at global scope if any of the macro candidates introduce
arbitrary names.
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.
Remove an early iteration of cycle-breaking in `PatternBindingEntryRequest`
that has been subsumed by the lazy computation of
`AbstractStorageDecl::hasStorage()`. We can now directly use
`hasStorage()` here.
Now that we've made accessor macro expansion more lazy, ensure that
when querying for init accessors (e.g., to build a memberwise
initializer), we also expand any accessor macros that might produce an
init accessor.
This is a partial step toward the real goal, which is that
`AbstractStorageDecl::getAccessor()` should lazily expand macros if
needed.
Update the Observable macro to document that it produces an `init`
accessor.
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.
This allows us to continue to accept Swift interface files created with
older versions of the Swift 5.9 compiler that emitted a spurious
`-> ()` on non-expression macro declarations.
Per SE-0397, a macro may only have a single freestanding macro role,
otherwise we would have an ambiguity in how a particular freestanding
macro would be expanded. Produce an error on such macro declarations.
Fixes rdar://110178899.
The compiler knows (from a macro declaration) what freestanding macro
role a macro implementation is expected to implement. Pass that through
to the macro expansion code itself, rather than guessing based on the
protocol conformances of the implementation type. We already use this
approach with attached macros, so this is more of the same.
Eliminates a crash and improves diagnostics when the freestanding macro
role and its implementation are out of sync, fixing rdar://110418969.
Default arguments for `init accessors` are not fully supported
at the moment, so we shouldn't attempt to synthesize them in
Sema just to crash during linking.
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.
