LLVM is presumably moving towards `std::string_view` -
`StringRef::startswith` is deprecated on tip. `SmallString::startswith`
was just renamed there (maybe with some small deprecation inbetween, but
if so, we've missed it).
The `SmallString::startswith` references were moved to
`.str().starts_with()`, rather than adding the `starts_with` on
`stable/20230725` as we only had a few of them. Open to switching that
over if anyone feels strongly though.
In the end this condition exists to avoid a BitCode Verifyer check that operates
off the scope, so looking for that directly is more future-proof.
rdar://123334375
To properly initialize the compiler instance on LLDB when debugging
embedded Swift programs, emit "-enable-embedded-swift" into the
DW_AT_APPLE_flags attribute of the compile unit.
When emitting a method definition in debug info, the compiler should
also emit the method's declaration, because LLVM LTO can't unify type
definitions when a child DIE is a full subprogram definition. This is
already the behavior for standard methods, this patch implements the
same behavior for witness and objc methods as well.
rdar://123334375
When generating full debug info for generic types, emit the
specification type as an opaque struct with the collection of
substituted generic parameters.
Generate the full debug info for generic structs. The strategy is to
emit one full entry for the generic type with archetypes, and one
forward declaration per instantiation of the generic type.
For example, given:
```
struct Pair<T, U> {
let t: T
let u: U
}
let p1 = Pair<Int, Double>(t: 1, u: 4.2)
let p2 = Pair<String, Bool>(t: "Hello", u: true)
```
DebugInfo will have one entry for Pair<T, U> which includes descriptions
of its fields, one forward declaration of Pair<Int, Double> and one
forward declaration of Pair<String, Bool>. This information is enough
for the algorithms of RemoteMirrors to reconstruct type information for
the fully instantiated types.
It's not clear that its worth keeping this as a
base class for SerializedAbstractClosure and
SerializedTopLevelCodeDecl, most clients are
interested in the concrete kinds, not only whether
the context is serialized.
The errorUnion type operation specifies how thrown error types are
combined when multiple errors are thrown in the same context. When
thrown error types can have type variables in them, we sometimes cannot
resolve the errorUnion until the type variables have substitutions. In
such cases, we need to persist the result of errorUnion in the
constraint solver.
Introduce the ErrorUnionType to do exactly that, and update the core
errorUnion operation to produce an ErrorUnionType when needed. At
present, this code is inert, because any errorUnion operation today
involves only concrete types. However, inference of thrown errors in
closures will introduce type variables, and depend on this.
We already need to track the inverses separate from the members in a
ProtocolCompositionType, since inverses aren't real types. Thus, the
only purpose being served by InverseType is to be eliminated by
RequirementLowering when it appears in a conformance requirement.
Instead, we introduce separate type InverseRequirement just to keep
track of which inverses we encounter to facilitate cancelling-out
defaults and ensuring that the inverses are respected after running
the RequirementMachine.
This patch stores the source code of macro in the source field of DIFile, which
can be used together with the DW_LLVM_LNCT_source extension to emit the source
code into DWARF debug info.
rdar://110926109
Replace the generation of debug info for enums from DW_TAG_union_type
to either DW_TAG_enumeration_type or DW_TAG_variant_part, as these
representation match Swift enums more closely.
