A new `RuntimeAttributeGenerator` is used to reference runtime
attribute generator functions synthesized by SILGen.
`#function` magic literal points to the declaration that declaration
attribute is attached to.
Each entry relates an attribute declaration to a list of all
declarations it's associated with together with a generator
function to acquire instance of the attribute value.
That does not work if there is a resilient class in the hiearchy from a
different module than the testable imported one. Rather treat an
internal but testable imported class as having resilient metadata.
The scenario that does not work assuming we can build a fragile layout
is the following.
FrameworkA is resilient and defines a public class `Base` with a stored field.
FrameworkB is resilient and defines an internal class `Sub` that inherits from
the class `Base` in FrameworkA and adds some fields. FrameworkB is compiled
with enable-testing.
The test case testable imports FrameworkB and accesses a field in the
internal class `Base` from FrameworkB. The test case only has access to
FrameworkA's public swiftinterface file and therefore does not know
`Base`'s layout. The layout computation for `Sub` cannot take the field
from `Base` into account and things fail silently.
rdar://103323275
Instead of a dynamic `swiftCxx.dylib` library, let's build a static library to simplify backdeployment and reduce potential compatibility difficulties in the future.
This also adds `NO_LINK_NAME` option to `add_swift_target_library` to prevent the CMake scripts from passing `-module-link-name` to swiftc when building a given module. This fixes linker errors, which would otherwise occur due to the force-load symbol name (`_swift_FORCE_LOAD_$xyz`) being emitted for the libraries that are now static (`swiftCxx`, `swiftstd`).
For spatial locality on startup.
Hide collocating metadata functions in a separate section behind a flag.
The default is not to collocate functions.
rdar://101593202
This reverts commit 3617b7603c, reversing
changes made to 58a519a5c1.
This causes issues for the linker and branches accross sections if
addresses are too far apart.
* Introduce TypeLayout Strings
Layout strings encode the structure of a type into a byte string that can be
interpreted by a runtime function to achieve a destroy or copy. Rather than
generating ir for a destroy/assignWithCopy/etc, we instead generate a layout
string which encodes enough information for a called runtime function to
perform the operation for us. Value witness functions tend to be quite large,
so this allows us to replace them with a single call instead. This gives us the
option of making a codesize/runtime cost trade off.
* Added Attribute @_GenerateLayoutBytecode
This marks a type definition that should use generic bytecode based
value witnesses rather than generating the standard suite of
value witness functions. This should reduce the codesize of the binary
for a runtime interpretation of the bytecode cost.
* Statically link in implementation
Summary:
This creates a library to store the runtime functions in to deploy to
runtimes that do not implement bytecode layouts. Right now, that is
everything. Once these are added to the runtime itself, it can be used
to deploy to old runtimes.
* Implement Destroy at Runtime Using LayoutStrings
If GenerateLayoutBytecode is enabled, Create a layout string and use it
to call swift_generic_destroy
* Add Resilient type and Archetype Support for BytecodeLayouts
Add Resilient type and Archetype Support to Bytecode Layouts
* Implement Bytecode assign/init with copy/take
Implements swift_generic_initialize and swift_generic_assign to allow copying
types using bytecode based witnesses.
* Add EnumTag Support
* Add IRGen Bytecode Layouts Test
Added a test to ensure layouts are correct and getting generated
* Implement BytecodeLayouts ObjC retain/release
* Fix for Non static alignments in aligned groups
* Disable MultiEnums
MultiEnums currently have some correctness issues with non fixed multienum
types. Disabling them for now then going to attempt a correct implementation in
a follow up patch
* Fixes after merge
* More fixes
* Possible fix for native unowned
* Use TypeInfoeBasedTypeLayoutEntry for all scalars when ForceStructTypeLayouts is disabled
* Remove @_GenerateBytecodeLayout attribute
* Fix typelayout_based_value_witness.swift
Co-authored-by: Gwen Mittertreiner <gwenm@fb.com>
Co-authored-by: Gwen Mittertreiner <gwen.mittertreiner@gmail.com>
This reverts commit 1f3e159cfe, reversing
changes made to 103b4a89c2.
Re-applies "IRGen: Co-locate metadata instatiation/completions/accessor
functions in a special section" for MachO only. The original change broke lldb
on aarch64 linux.
rdar://102481054
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.
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`.
This lifts the requirement for the user to explicitly add `import Cxx` in Swift code that relies on protocols from the `Cxx` module, such as `CxxSequence`.
This commit begins to generate correct metadata for @_objcImplementation extensions:
• Swift-specific metadata and symbols are not generated.
• For main-class @_objcImpls, we visit the class to emit metadata, but visit the extension’s members.
• Includes both IR tests and executable tests, including coverage of same-module @objc subclasses, different-module @objc subclasses, and clang subclasses.
The test cases do not yet cover stored properties.
In preparation for moving to llvm's opaque pointer representation
replace getPointerElementType and CreateCall/CreateLoad/Store uses that
dependent on the address operand's pointer element type.
This means an `Address` carries the element type and we use
`FunctionPointer` in more places or read the function type off the
`llvm::Function`.
The _swift5_entry section contains a relative pointer to the entry-point
function (spelled variously _main and @main depending on context).
Support differentiating whether that entry point originates from a type
annotated @main or something else (i.e. main.swift) via a second
relative-pointer-sized field. For now, that field is just a bit: 1 if
there is a type annotated @main, 0 otherwise. In the future, that field
could be a relative pointer to the type descriptor for the type.
Modify IRGen to emit “anonymous” string constants with names of the form `@.str.<len>.<contents>` (with a special mangling for internal `\0` characters). This makes it much easier to write IRGen tests that check for the contents of strings, because matching the constant name also implies that the constant has the expected content.
We previously eagerly emitted such functions to
ensure that their name data is emitted through the
profiler increment. Now that are able to emit the
profile name data separately, this is unnecessary,
and we can avoid emitting their definitions.
It decides which functions need stack protection.
It sets the `needStackProtection` flags on all function which contain stack-allocated values for which an buffer overflow could occur.
Within safe swift code there shouldn't be any buffer overflows.
But if the address of a stack variable is converted to an unsafe pointer, it's not in the control of the compiler anymore.
This means, if there is any `address_to_pointer` instruction for an `alloc_stack`, such a function is marked for stack protection.
Another case is `index_addr` for non-tail allocated memory.
This pattern appears if pointer arithmetic is done with unsafe pointers in swift code.
If the origin of an unsafe pointer can only be tracked to a function argument, the pass tries to find the root stack allocation for such an argument by doing an inter-procedural analysis.
If this is not possible, the fallback is to move the argument into a temporary `alloc_stack` and do the unsafe pointer operations on the temporary.
rdar://93677524
Extended existential type shapes can trigger this by introducing
more entities (and thus causing GlobalVars to be rehashed) during
the lazy-emission callback.
Fixes rdar://98995607
Include the parent `ModuleDecl` when serializing a `SILFunction` so that it is available on deserialized functions even though the full `DeclContext` is not present. With the parent module always available we can reliably compute whether the `SILFunction` comes from a module that was imported `@_weakLinked`.
Serialize the `DeclContext` member of `SILFunction` so that it can be used to look up the module that a function belongs to in order to compute weak import status.
Resolves rdar://98521248
