Rename LLDB_ALLOW_STATIC_BINDINGS to LLDB_USE_STATIC_BINDINGS and make
LLDB use the static bindings unconditionally when it's set. The current
variable is opaque because it allows LLDB to use the static bindings,
but only if SWIG is not found. If an incompatible version of swig is
found, it reports a fatal error. This serves no purpose other than to
confuse the user.
The corresponding LLDB patch simplifies things and makes the variable do
what you expect. When enabled, LLDB uses the static bindings. When
disabled, we try to generate them with SWIG.
This patch modifies the build scripts to pass the new variable.
This removes it from the AST and largely replaces it with AnyObject
at the SIL and IRGen layers. Some notes:
- Reflection still uses the notion of "unknown object" to mean an
object with unknown refcounting. There's no real reason to make
this different from AnyObject (an existential containing a
single object with unknown refcounting), but this way nothing
changes for clients of Reflection, and it's consistent with how
native objects are represented.
- The value witness table and reflection descriptor for AnyObject
use the mangling "BO" instead of "yXl".
- The demangler and remangler continue to support "BO" because it's
still in use as a type encoding, even if it's not an AST-level
Type anymore.
- Type-based alias analysis for Builtin.UnknownObject was incorrect,
so it's a good thing we weren't using it.
- Same with enum layout. (This one assumed UnknownObject never
referred to an Objective-C tagged pointer. That certainly wasn't how
we were using it!)
Teach SILGen to emit a separate SIL function to capture the
initialization of the backing storage type for a wrapped property
based on the wrapped value. This eliminates manual code expansion at
every use site.
That is: types, globals, C functions, and enumerators, including a
discussion of import-as-member for each. Still more to come:
swift_name for properties, methods, and struct fields.
`destroy_addr` is never semantically a "no-op". Just because an
instruction can be safely eliminated does not mean the instruction has
no semantics! That would be like saying we could move an unknown
memory read below an otherwise dead store!
Even if a destroy_addr of a trivial type is a no-op, we must not end up with using such a value after a destroy_addr.
The fix is to also handle aggregate fields of trivial types in MemoryLifetime.
rdar://problem/55125020
The archetype mangling does not have enough information to accurately recover the associated type
at runtime. This fixes rdar://problem/54084733.
Although this changes the mangling in both runtime and symbols, this should not affect ABI, because
there is no way for associated types of opaque types to be surfaced in the types of public
declarations today.
Includes enums in all their flavors, plus swift_wrapper structs.
Planned future content:
- Methods, initializers, properties
- "Omit-needless-words" rules
- NSError
- Boolean properties
- Inferred default arguments
- Factory methods as initializers
- Protocols (mainly just that they check for collision)
- CF types (low-priority since non-Apple people can't make them)
- Custom names, including import-as-member and import-as-accessor
- swift_private
This commit adds docs for copy_unmanaged_value to SIL.rst as requested by
@eeckstein in #26839. I noticed while doing the PR that copy_unowned_value was
also not documented, so I added docs for it as well as a bonus. = ).
This commit introduces a CMake target for each component, adds install targets
for them, and switches build-script-impl to use the target `install-components`
for installation. Each of the targets for each component depends on each
of the individual targets and outputs that are associated with the
corresponding swift-component.
This is equivalent to what already exists, because right now install rules are
only generated for components that we want to install. Therefore, this commit
should be an NFC.
This is a resubmission (with modifications) of an earlier change. I originally
committed this but there were problems with some installation rules.
In case of a tuple as value type, the initializer and setter takes the tuple elements as separate arguments. This was just not handled in the assign_by_wrapper instruction lowering.
rdar://problem/53866473
`partial_apply` does not own `@inout_aliasable` arguments, so the original description "the closure does however take ownership of the partially applied arguments" is not accurate. This patch makes things clear.
This flag adds diagnostic names to the end of their messages, e.g. 'error: cannot convert value of type '[Any]' to specified type '[Int]' [cannot_convert_initializer_value]'. It's intended to be used for debugging purposes when working on the compiler.
