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 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
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.
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 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.
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.
Raw identifiers are backtick-delimited identifiers that can contain any
non-identifier character other than the backtick itself, CR, LF, or other
non-printable ASCII code units, and which are also not composed entirely
of operator characters.
To pave the way for the new experimental feature which will operate on '@const' attribute and expand the scope of what's currently handled by '_const' without breaking compatibility, for now.
Our Bazel builds have become more strict about libc++
dependencies recently, so these are required to pick up
declarations of `malloc` and `uint32_t`, respectively.
The issue here is that the demangler (since we have a postfix mangling) parses
parameters/results/etc and then uses earlier postfix type arguments to attach
the relevant types to the parameters/results/etc. Since the flag for a sending
result was placed in between the parameters and results, we get an off by one
error.
Rather than fix that specific issue by introducing an offset for the off by one
error, I used the fact that the impl-function part of the mangling is not ABI
and can be modified to move the bit used to signify a sending result to before
the parameters so the whole problem is avoided.
I also while I was doing this looked through the sending result mangling for any
further issues and fixed them as I found them.
rdar://141962865
Fixes the immediate problem, but the presence of demangling code in the
runtime means that we'll need a follow-up to fix the compiler so that it
doesn't try to use the demangler to materialize metadata for function types
that have both isolation and a sending result.
rdar://142443925
Today ParenType is used:
1. As the type of ParenExpr
2. As the payload type of an unlabeled single
associated value enum case (and the type of
ParenPattern).
3. As the type for an `(X)` TypeRepr
For 1, this leads to some odd behavior, e.g the
type of `(5.0 * 5).squareRoot()` is `(Double)`. For
2, we should be checking the arity of the enum case
constructor parameters and the presence of
ParenPattern respectively. Eventually we ought to
consider replacing Paren/TuplePattern with a
PatternList node, similar to ArgumentList.
3 is one case where it could be argued that there's
some utility in preserving the sugar of the type
that the user wrote. However it's really not clear
to me that this is particularly desirable since a
bunch of diagnostic logic is already stripping
ParenTypes. In cases where we care about how the
type was written in source, we really ought to be
consulting the TypeRepr.
`Builtin.FixedArray<let N: Int, T: ~Copyable & ~Escapable>` has the layout of `N` elements of type `T` laid out
sequentially in memory (with the tail padding of every element occupied by the array). This provides a primitive
on which the standard library `Vector` type can be built.
Fred Riss
Pavel Yaskevich
Mike Ash
Kavon Farvardin
Joe Groff
Tim Kientzle
Anthony Latsis
Erik Eckstein
Aidan Hall
Meghana Gupta
Charles Zablit
Meghana Gupta
Janat Baig
Adrian Prantl
Slava Pestov
Artem Chikin
Nate Chandler
Hamish Knight
Amritpan Kaur
Konrad `ktoso` Malawski
Tony Allevato
Tony Allevato
Michael Gottesman
John McCall
Saleem Abdulrasool
Kuba Mracek
Alejandro Alonso