https://github.com/swiftlang/swift/pull/72659 turned out to have some
source compatibility fallout that we need to fix. Instead of introducing
yet another brittle compatibility hack, stop emitting errors about a
missing `any` altogether until a future language mode.
Besides resolving the compatibility issue, this will encourage
developers to adopt any sooner and grant us ample time to gracefully
address any remaining bugs before the source compatibility burden
resurfaces.
A subsequent commit adds a diagnostic group that will allow users to
escalate these warnings to errors with `-Werror ExistentialAny`.
When we are using diagnostic transactions to disable immediate emission
of diagnostics, `DiagnosticEngine::hadAnyError()` no longer accurately
reports whether an error occurred. Thread the DiagnosticTransaction
into the ConstraintSystem so we can also check whether it contains an
error before emitting the fallback diagnostic.
Fixes rdar://128272346.
Find all the usages of `--enable-experimental-feature` or
`--enable-upcoming-feature` in the tests and replace some of the
`REQUIRES: asserts` to use `REQUIRES: swift-feature-Foo` instead, which
should correctly apply to depending on the asserts/noasserts mode of the
toolchain for each feature.
Remove some comments that talked about enabling asserts since they don't
apply anymore (but I might had miss some).
All this was done with an automated script, so some formatting weirdness
might happen, but I hope I fixed most of those.
There might be some tests that were `REQUIRES: asserts` that might run
in `noasserts` toolchains now. This will normally be because their
feature went from experimental to upcoming/base and the tests were not
updated.
Instead of emitting an warning to the diagnostic engine, return the
plugin loading error as the result of the request. So that the user
can decide to emit it as a warning or an error.
Applying generic arguments to a variadic generic type uses the
PackMatcher to build a mapping between generic parameters and
arguments.
The PackMatcher is symmetric, so there was an unexpected failure
mode that wasn't handled: if the variadic generic type had some
non-pack parameters, but the argument list was a single pack
expansion type, the match would succeed, grouping all of the
generic parameters into a single match.
This is non-sensical, so we need to explicitly check for this
case and diagnose it. This requires a new diagnostic, since
otherwise the general diagnostic we emit for variadic generic
type mismatches doesn't make sense, since it's complaining
about there being too few generic parameters.
Fixes rdar://116713961 / https://github.com/apple/swift/issues/69012.
This is a very large diagnostic, where the second half is mostly aimed
at macro authors rather than clients. Cut it down to the base
diagnostic.
Resolves rdar://113646544.
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.
`TypeChecker::checkExistentialTypes` has decl-specific logic and backs out without invoking `ExistentialTypeVisitor` on `TypeDecl`s, but `MacroExpansionDecl` isn't a type decl and would fall into `ExistentialTypeVisitor` which will visit its expansion. The caller of `checkExistentialTypes` already visits auxiliary decls, so here we should only visit arguments and generic arguments of a macro.
Fixes a case where a declaration macro produces a type that conforms to a PAT. We now also run existential diagnostics on generic arguments on a `MacroExpansionDecl` that was previously not handled.
Note: I tried bailing out in `walkToDeclPre` but we should really visit macro arguments and generic arguments. Not walking expansions in `ExistentialTypeVisitor` is also not the right fix because we need to be able to visit macro expansions in arguments.
rdar://109779928
We should no longer say "macro implementation must be provided via '-load-plugin-library'" as there are multiple ways to pick up a macro dependency. Here's an improved version:
> warning: external macro implementation type 'MissingModule.MissingType' could not be found for macro 'missingMacro1'; the type must be public and provided by a macro target in a Swift package, or via '-plugin-path' or '-load-plugin-library'
The root problem is that `ResolveMacroRequest` was shortcuting after calling `lookupMacros`. When type-checking a freestanding macro, it shouldn't need to call `lookupMacros` at all, but should go straight to CSGen.
rdar://108280416
The macro tests were all using "REQUIRES: OS=macosx" as a proxy for
"have the Swift Swift parser". There was an existing feature for this,
but it was just checking whether the path was passed through. Fix that
to use the same variable as in CMake.
Also remove all extraneous `-I` and `-L` to the host libs in the target
invocations.
How did we go this long without having the right context? Who knows.
The fix is trivial and obvious.
The failure mode here is that we wouldn't get an appropriate generic
context in the result type of a macro, so we would complain about
generic parameters not meeting their own generic requirements.
In preparation for supporting macros that are defined in terms of other
macros, adopt macro definition checking provided by the
`MacroDeclSyntax.checkDefinition` operation (implemented in
swift-syntax). Use this in lieu of the checking on the C++ side.
This required me to finally fix an issue with the source ranges for
Fix-Its, where we were replacing the leading/trailing trivia of nodes
along with the node itself, even though that's incorrect: we should
only replce the node itself, and there are other Fix-It kinds for
replacing leading or trailing trivia.
SE-0382 allows macro parameters to have default arguments. Enable these
default arguments, with the normal type checking rules. One
significant quirk to this implementation is that the actual default
argument values don't make it to the macro implementation. This is a
previously-unconsidered design problem we'll need to address.
Tracked by rdar://104043987.
To enable the declaration and use of macros from a newer Swift
compiler, when the standard library is from an older Swift compiler
that doesn't provide a declaration of `externalMacro`, short-circuit
the type-checking of `#externalMacro(module: "A", type: "B")` when it
is used to declare a new macro.
- Use the name lookup table instead of adding members from a macro expansion to the parent decl context.
- Require declaration macros to specify introduced names and used the declared names to guide macro expansions lazily.
Rename `ResolveAttachedMacroRequest` to `ResolveMacroRequest` and make use of the request in freestanding declaration macro type checking. Add support for type-checking generic arguments on `MacroExpansionDecl`.
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.
Align the grammar of macro declarations with SE-0382, so that macro
definitions are parsed as an expression. External macro definitions
are referenced via a referenced to the macro `#externalMacro`. Define
that macro in the standard library, and recognize uses of it as the
definition of other macros to use externally-defined macros. For
example, this means that the "stringify" macro used in a lot of
examples is now defined as something like this:
@expression macro stringify<T>(_ value: T) -> (T, String) =
#externalMacro(module: "MyMacros", type: "StringifyMacro")
We still parse the old "A.B" syntax for two reasons. First, it's
helpful to anyone who has existing code using the prior syntax, so they
get a warning + Fix-It to rewrite to the new syntax. Second, we use it
to define builtin macros like `externalMacro` itself, which looks like this:
@expression
public macro externalMacro<T>(module: String, type: String) -> T =
Builtin.ExternalMacro
This uses the same virtual `Builtin` module as other library builtins,
and we can expand it to handle other builtin macro implementations
(such as #line) over time.
Always parse macro expansions, regardless of language mode, and
eliminate the fallback path for very, very, very old object literals
like `#Color`. Instead, check for the feature flag for macro
declaration and at macro expansion time, since this is a semantic
restriction.
While here, refactor things so the vast majority of the macro-handling
logic still applies even if the Swift Swift parser is disabled. Only
attempts to expand the macro will fail. This allows us to enable the
macro-diagnostics test everywhere.
