Deserialization recovery lead the compiler to drop public constructors
overridding internal constructors. This limits the logic to dropping the
overriding relationship instead of the whole constructor. This applies
when the overriden constructor fails to deserialize and only when the
overriding relationship was marked as not affecting ABI.
rdar://104704832
- SILPackType carries whether the elements are stored directly
in the pack, which we're not currently using in the lowering,
but it's probably something we'll want in the final ABI.
Having this also makes it clear that we're doing the right
thing with substitution and element lowering. I also toyed
with making this a scalar type, which made it necessary in
various places, although eventually I pulled back to the
design where we always use packs as addresses.
- Pack boundaries are a core ABI concept, so the lowering has
to wrap parameter pack expansions up as packs. There are huge
unimplemented holes here where the abstraction pattern will
need to tell us how many elements to gather into the pack,
but a naive approach is good enough to get things off the
ground.
- Pack conventions are related to the existing parameter and
result conventions, but they're different on enough grounds
that they deserve to be separated.
Introduce a new flag `-export-as` to specify a name used to identify the
target module in swiftinterfaces. This provides an analoguous feature
for Swift module as Clang's `export_as` feature.
In practice it should be used when a lower level module `MyKitCore` is
desired to be shown publicly as a downstream module `MyKit`. This should
be used in conjunction with `@_exported import MyKitCore` from `MyKit`
that allows clients to refer to all services as being part of `MyKit`,
while the new `-export-as MyKit` from `MyKitCore` will ensure that the
clients swiftinterfaces also use the `MyKit` name for all services.
In the current implementation, the export-as name is used in the
module's clients and not in the declarer's swiftinterface (e.g.
`MyKitCore`'s swiftinterface still uses the `MyKitCore` module name).
This way the module swiftinterface can be verified. In the future, we
may want a similar behavior for other modules in between `MyKitCore` and
`MyKit` as verifying a swiftinterface referencing `MyKit` without it
being imported would fail.
rdar://103888618
The attached and freestanding macro attributes use the same parsing
logic and representation, so generalize the "attached" attribute into
a more general "macro role" attribute.
When writing decls to a swiftmodule files, the serialization logic
evaluates whether the decl will be safe to deserialize. This is inferred
from the access level of the decl, whether it's local, if the module is
built for testing, etc. If the decl in unsafe to deserialize, a record
will be written down before the decl itself in the swiftmodule file.
On the reader side, attempting to deserialize a decl marked as unsafe
raises a deserialization error early. This error is handled by the existing
deserialization recovery logic.
In theory, we want to consider as safe only decls that are actually needed by
the client. Marking as many internal details as possible as unsafe will
prevent more errors. Getting the right scope may require more work in
the future.
This change reflects the behavior of `DeclAttribute.printImpl` that
prints the `override` keyword in a swiftinterface only when the
overriden decl is also public.
This issue was detected when working on deserialization safety by public
overrides of private functions in the following tests:
test/Interpreter/vtables_multifile.swift
test/Interpreter/vtables_multifile_testable.swift
test/SILGen/accessibility_vtables_testable.swift
test/SILGen/accessibility_vtables_usableFromInline.swift
test/SILGen/vtables_multifile.swift
Describe attached macros with the `@attached` attribute, providing the
macro role and affected names as arguments to the macro. The form of
this macro will remain the same as it gains other kinds of attached
macro roles beyond "accessor".
Remove the "accessors" role from `@declaration`, which will be going
away.
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.
Local discriminators for named entities are currently being set by the
parser, so entities not created by the parser (e.g., that come from
synthesized code) don't get local discriminators. Moreover, there is
no checking to ensure that every named local entity gets a local
discriminator, so some entities would incorrectly get a local
discriminator of 0.
Assign local discriminators as part of setting closure discriminators,
in response to a request asking for the local discriminator, so the
parser does not need to track this information, and all local
declarations---including synthesized ones---get local discriminators.
And add checking to make sure that every entity that needs a local
discriminator gets assigned one.
There are a few interesting cases in here:
* There was a potential mangling collision with local property
wrappers because their generated variables weren't getting local
discriminators
* $interpolation variables introduced for string interpolation weren't
getting local discriminators, they were just wrong.
* "Local rename" when dealing with captures like `[x]` was dependent on
the new delcaration of `x` *not* getting a local discriminator. There
are funny cases involving nesting where it would do the wrong thing.
`getValue` -> `value`
`getValueOr` -> `value_or`
`hasValue` -> `has_value`
`map` -> `transform`
The old API will be deprecated in the rebranch.
To avoid merge conflicts, use the new API already in the main branch.
rdar://102362022
Although the declaration of macros doesn't appear in Swift source code
that uses macros, they still operate as declarations within the
language. Rework `Macro` as `MacroDecl`, a generic value declaration,
which appropriate models its place in the language.
The vast majority of this change is in extending all of the various
switches on declaration kinds to account for macros.
Push the top level logic for writing out swiftmodules and associated files into the frontend library which has access to all the necessary dependencies.
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`.
* [SILOptimizer] Add prespecialization for arbitray reference types
* Fix benchmark Package.swift
* Move SimpleArray to utils
* Fix multiple indirect result case
* Remove leftover code from previous attempt
* Fix test after rebase
* Move code to compute type replacements to SpecializedFunction
* Fix ownership when OSSA is enabled
* Fixes after rebase
* Changes after rebasing
* Add feature flag for layout pre-specialization
* Fix pre_specialize-macos.swift
* Add compiler flag to benchmark build
* Fix benchmark SwiftPM flags
