Not aliasing the stdlib should allows it to be used in inlinable code.
Since builtin isn't imported explicitly, references to it shouldn't use
the alias.
rdar://104582241
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.
If the callee is a non-generic thunk which calls a (not inlinable) generic function in the defining module,
it's more efficient to not devirtualize, but call the non-generic thunk - even though it's done through the witness table.
Example:
```
protocol P {
func f(x: [Int]) // not generic
}
struct S: P {
func f(x: some RandomAccessCollection<Int>) { ... } // generic
}
```
In the defining module, the generic conformance can be fully specialized (which is not possible in the client module, because it's not inlinable).
rdar://102623022
If a type conforms to a protocol that has a public `$Storage`/`$storage`
requirement the synthesis should produce a public `$Storage`/`$storage`
implementation as well to match the requirement.
Resolves: rdar://103270262
Introduce a new behavior when printing references to modules with an
`export_as` definition. Use the `export_as` name in the public swiftinterface
and the real module name in the private swiftinterface.
This has some limits but should still be an improvement over the current
behavior. First, the we use the `export_as` names only for references to clang
decls, not Swift decls with an underlying module defining an `export_as`.
Second, we always print the `export_as` name in the public swiftinterface,
even in the original swiftinterface file when the `export_as` target is likely
not know, so that generated swiftinterface is still broken.
This behavior is enabled by the flags `-enable-experimental-feature ModuleInterfaceExportAs`
or the `SWIFT_DEBUG_USE_EXPORTED_MODULE_NAME_IN_PUBLIC_ONLY` env var. We may
consider turning it on by default in the future.
rdar://98532918
Macros are an experimental feature, as such are not available on
non-asserts compilers.
Adding requires asserts to remaining experimental macro tests.
- ModuleInterface/macros.swift
- Serialization/macros.swift
This new flag should allow module authors to specify allowable client list. This list is printed
in the textual module interface. Diagnostics support can come later.
In AliasModuleNames, avoid wrongfully printing aliased names for modules
that were not aliased. This can happen in the case of modules indirectly
imported via a reexport.
rdar://102262019
https://github.com/apple/swift/pull/42041 introduced a centralized mechanism for adding the `nonisolated` attribute to synthesized decls but did not clean up the existing code that was already doing so for `Hashable` conformances.
Resolves rdar://102106591
Ambiguities are introduced in generated swiftinterfaces when a type
shares a name with a module (i.e. XCTest). This workaround uses the
module-alias feature to avoid these ambiguities. Writing module
references with a distinguishable prefix should allow normal
type-checking to avoid the usual ambiguities.
We should still aim for a proper fully-qualified named syntax, but this
may help in the mean time.
rdar://101969500
This flag restricts availability of certain symbols to ensure the code cannot use declarations that are explicitly unavalable to extensions. This restriction should be passed down to dependency modules also.
