These were originally meant to be no-return functions since they're going to abort. They were accidentally changed to no-discard functions despite not having a return value.
The internal compiler headers should not include swift shim headers. Removing this dependency allows libSwift to import Swift compiler headers (otherwise, we get name conflics, because we import SwiftShims headers twice: from the source includes and build includes).
Distributed thunks were using the same mangling as direct method
reference thunks (i.e., for "super" calls). Although not technically
conflicting so long as actors never gain inheritance, it's confusing
and could cause problems in the future. So, introduce a distinct
mangling for distributed thunks and plumb them through the demangling
and remangler.
If you had a type alias (for instance) with its context set to a static
bound generic function, the generic arguments were remangled in the wrong
place because Node::Kind::Static wasn't handled properly in a couple of
functions. Fix that.
rdar://82870372
When back-deploying concurrency support, do not use the standard
substitutions for _Concurrency-defined types (such as `Task`) in type
metadata because older Swift runtimes will not be able to demangle
them. Instead, use the full mangled names so the runtime can still
demangle them appropriately.
Addresses rdar://82931890.
Defining DEMANGLE_ASSERT as assert() is simple but messes up the file/line
information from assert(). Make a dedicated assertion failure function and use
that instead to fix.
Also enable some tests that were disabled because they triggered abort()
calls in the remanglers.
rdar://79725187
Because DEMANGLER_ASSERT() might cause the remanglers to return a ManglingError
with the code ManglingError::AssertionFailed, it's useful to have a line number
in the ManglingError as well as the other information. This is also potentially
helpful for other cases where the code is used multiple times in the remanglers.
rdar://79725187
First pass at adding error handling to the actual Remangler. There are
still some assert() calls at this point that I'm thinking about.
rdar://79725187
Mangling can fail, usually because the Node structure has been built
incorrectly or because something isn't supported with the old remangler.
We shouldn't just terminate the program when that happens, particularly
if it happens because someone has passed bad data to the demangler.
rdar://79725187
There can be, currently, up to eight child nodes for a FunctionType.
OldRemangler seemed to think there could only be three, while NodePrinter
plumped for six.
rdar://82252704
Added a special test for getObjCClassByMangledName; this needs testing
separately as it uses the DecodedMetadataBuilder, which doesn't get exercised
by the normal demangling tests.
Added all the test cases from rdar://63485806, rdar://63488139, rdar://63496478,
rdar://63410196 and rdar://68449341. The test cases from rdar://63485806 are
disabled for now because the problem there is the error handling mechanism (or
lack thereof), rather than us not handling errors.
Fixes the remaining cases from
rdar://63488139
rdar://63496478
We've had a couple of instances where isSpecialized() crashed while while trying
to use remote mirror to inspect a process that had itself crashed. I can't see
any obvious mechanism for that to happen, so for now I decided to make
isSpecialized() more robust in the hope that if it happens again we'll get more
information and might be able to work out how it happened.
rdar://74394596
It's trivially easy to drive the remanglers, the type decoder and the node
printer into a situation where they will overflow the process's stack. For the
compiler, this is fine (though not great), but for the runtime it's a no-no.
This changeset imposes recursion depth limits to prevent uncontrolled stack
overruns.
rdar://68449341
The OldDemangler was still spelling Builtin.Vec4xFPIEEE16 as
Builtin.Vec4xFloat16, which meant that feeding its output to the new
Remangler caused it to fail with "fatal error: unexpected builtin
vector type".
rdar://63485806
PartialApplyForwarders can apparently have no children in some cases,
so avoid calling mangleSingleChildNode() if that happens in order to avoid
a crash.
rdar://63678141
The Demangler can wrap types in a Node::Kind::Type node; these need to be
handled by following the node's first child pointer. Failing to do this led to
a crash or assertion failure in some cases.
rdar://63678171
The Demangler can sometimes output ArgumentTuples containing a single argument
without placing that argument inside a Tuple node. OldRemangler failed to take
account of this and either crashed or failed with an assertion failure depending
on whether assertions were enabled or not.
rdar://63678072
Isolated parameters are part of function types. Encode them in function
type manglings and metadata, and ensure that they round-trip through
the various mangling and metadata facilities. This nails down the ABI
for isolated parameters.
ImplFunctionType nodes inside optionals are wrapped in Type nodes,
which means that isSimpleType() needs to look through the Type node
when we're printing them, or we fail to wrap them with parentheses.
<rdar://67915116>
Implement name mangling, type metadata, runtime demangling, etc. for
global-actor qualified function types. Ensure that the manglings
round-trip through the various subsystems.
Implements rdar://78269642.
Introduce a second level of standard substitutions to the mangling,
all of the form `Sc<character>`, and use it to provide standard
substitutions for most of the _Concurrency types.
This is a precursor to rdar://78269642 and a good mangling-size
optimization in its own right.
