- Move the original intro into a "Background" section
- Link to SE-0193 (@inlinable) and SE-0260 (@frozen)
- Note (suggested by @Gankra) on why it's safe to add stored
properties to a struct
- Remove some bits that reference the content removed in earlier
commits
- Other minor copyediting
By convention, most structs and classes in the Swift compiler include a `dump()` method which prints debugging information. This method is meant to be called only from the debugger, but this means they’re often unused and may be eliminated from optimized binaries. On the other hand, some parts of the compiler call `dump()` methods directly despite them being intended as a pure debugging aid. clang supports attributes which can be used to avoid these problems, but they’re used very inconsistently across the compiler.
This commit adds `SWIFT_DEBUG_DUMP` and `SWIFT_DEBUG_DUMPER(<name>(<params>))` macros to declare `dump()` methods with the appropriate set of attributes and adopts this macro throughout the frontend. It does not pervasively adopt this macro in SILGen, SILOptimizer, or IRGen; these components use `dump()` methods in a different way where they’re frequently called from debugging code. Nor does it adopt it in runtime components like swiftRuntime and swiftReflection, because I’m a bit worried about size.
Despite the large number of files and lines affected, this change is NFC.
- remove numbers on steps, they get out of sync and auto-numbering headers doesn't work
- correct some header titles
- re-render the tree to be ascii pretty
- split out "one-time setup" from "getting started"
- fix invocation of cmake for toolchain
- fix libdispatch build rules
- convert libdispatch build rules to be copy-paste friendly
- add libdispatch test instructions
...and function builders, even though those haven't formally been
accepted to the language yet. (This description of property wrappers
is also a bit optimistic; at the time of this writing, they haven't
been implemented for top-level variables yet.)
The previous wording referred to a method or property satisfying a
protocol requirement as an "override", which both Clang and the Swift
Clang Importer use internally sometimes. But most people who program
Objective-C (or Swift) don't think of this as an override, so this
document shouldn't use that language. (Thanks, Varun!)
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.
