DemangleInitRAII saves and restores NumWords but not the Words[] array
itself. When a nested demangleSymbol/demangleType call processes
identifiers, it overwrites Words[] entries with StringRefs pointing
into its own Text buffer. After ~DemangleInitRAII restores the outer
NumWords, those entries still reference the inner (now-destroyed)
buffer. The outer demangling then hits a word substitution and reads
freed memory through the stale StringRef.
In practice this is triggered by MetadataReader::demangle(): the
symbolic reference resolver calls buildContextManglingForSymbol which
calls dem.demangleSymbol() on the same Demangler. The inner symbol's
identifiers overwrite Words[] with pointers into the
ParentContextDescriptorRef's temporary string. When the resolver
returns and the PCCDR is destroyed, the outer demangleType accesses
dangling Words[] entries via word substitution identifiers.
The fix adds Words[] to DemangleInitRAII's saved/restored state.
rdar://172223904
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This just renames two `Errors.cpp` to different names to accomodate the
compaction of `libDemangling` into `swiftCoreRuntime`. This is important
as when statically linked we end up with two members with the same name
which produces a linker issue:
```
libswiftCore.lib(Errors.cpp.obj) : warning LNK4255: library contain multiple objects of the same name; linking object as if no debug info
```
This avoids coalescing checked and unchecked handlers with the same types, which results in runtime crashes as they are not compatible.
We have a separate mangling for predefined handlers, TZ, which is unused. Repurpose this for checked handlers. Unchecked handlers keep their existing mangling with Tz.
rdar://152263818
There may be 3 or 4 children here dependending on whether the peer
expansion is being used as the context for another macro expansion,
make sure the discriminator in these cases always comes after the
operator. No test case as it's covered by the next commit.
For reparenting, we rely on a default associated conformance witness accessor
to build the witness table for 'Self: NewParent' at runtime. This means that
when mangling the symbol for such a descriptor, we need support for there
being no associated type at all; it's just tau_0_0 aka Self as the subject.
This patch extends _default_ associated conformance witness accessor mangling
to support a GenericTypeParamType for the subject, as the non-default accessors
already quietly did have support; see `mangleAssociatedConformanceDescriptor`.
It was quiet in the sense that there was no demangling support for it, nor
documentation about it either. So I've brought both kinds of witness accessor
manglings up-to-par, without extending the `assoc-type-name` grammar itself.
This updates a large number of internal symbols, function names,
and types to match the final approved terminology. Matching the
surface language terminology and the compiler internals should
make the code easier for people to understand into the future.
This is currently not wired up to anything. I am going to wire it up in
subsequent commits.
The reason why we are introducing this new Builtin type is to represent that we
are going to start stealing bits from the protocol witness table pointer of the
Optional<any Actor> that this type is bitwise compatible with. The type will
ensure that this value is only used in places where we know that it will be
properly masked out giving us certainty that this value will not be used in any
manner without it first being bit cleared and transformed back to Optional<any
Actor>.
So far, constant propagated arguments could only be builtin literals.
Now we support arbitrary structs (with constant arguments), e.g. `Int`.
This requires a small addition in the mangling scheme for function specializations.
Also, the de-mangling tree now looks a bit different to support a "tree" of structs and literals.
This patch adds parsing and extracting of the Swift reflection
metadata data segments from within the WebAssembly DATA section and
tests it using swift-reflection-dump. This is needed to allow LLDB to
acces Swift reflection metadata when attached to WebAssembly
processes.
rdar://159217213
This patch adds a new SymbolicExtendedExistentialTypeRef kind, and
wires it up in TypeDecoder, TypeRefBuilder, TypeLowering, and
ASTDemangler.
This is tested indirectly via the matching LLDB commit.
We sometimes mangle SILFunctionTypes when generating debug info
for reabstraction thunks, and these can have various exotic
parameter and result attributes. Two recent additions were
never plumbed through the mangler, causing assertion failures
when emitting debug info.
Fixes rdar://153730847.
We stack-allocate 512 of these entries for a temporary cache, so the entry size matters a great deal. Shrink it from 3 words to 2 by storing treatAsIdentifier in the low bit of the node pointer.
rdar://149685318
If a retroactive conformance is conditional and the subject type of a
conditional requirement is an opaque archetype, the mangler would
emit a mangling using the "HO" operator which the demangler did not
understand.
Implement de/remangler support for the "HO" operator.
Fixes rdar://149801864.
* [CS] Decline to handle InlineArray in shrink
Previously we would try the contextual type `(<int>, <element>)`,
which is wrong. Given we want to eliminate shrink, let's just bail.
* [Sema] Sink `ValueMatchVisitor` into `applyUnboundGenericArguments`
Make sure it's called for sugar code paths too. Also let's just always
run it since it should be a pretty cheap check.
* [Sema] Diagnose passing integer to non-integer type parameter
This was previously missed, though would have been diagnosed later
as a requirement failure.
* [Parse] Split up `canParseType`
While here, address the FIXME in `canParseTypeSimpleOrComposition`
and only check to see if we can parse a type-simple, including
`each`, `some`, and `any` for better recovery.
* Introduce type sugar for InlineArray
Parse e.g `[3 x Int]` as type sugar for InlineArray. Gated behind
an experimental feature flag for now.