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.
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.
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.
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
Mangling this information for future directions like component lifetimes
becomes complex and the current mangling scheme isn't scalable anyway.
Deleting this support for now.
Instead of adding a "flag" (`m` in `...Tgm5`) make it more generic to allow to drop any unused argument.
Add all dropped arguments with a `t<n-1>` (where `<n-1>` is empty for n === 0). For example `...Ttt2g5`.
This corresponds to the parameter-passing convention of the Itanium C++
ABI, in which the argument is passed indirectly and possibly modified,
but not destroyed, by the callee.
@in_cxx is handled the same way as @in in callers and @in_guaranteed in
callees. OwnershipModelEliminator emits the call to destroy_addr that is
needed to destroy the argument in the caller.
rdar://122707697
A few things:
1. Internally except for in the parser and the clang importer, we only represent
'sending'. This means that it will be easy to remove 'transferring' once enough
time has passed.
2. I included a warning that suggested to the user to change 'transferring' ->
'sending'.
3. I duplicated the parsing diagnostics for 'sending' so both will still get
different sets of diagnostics for parsing issues... but anywhere below parsing,
I have just changed 'transferring' to 'sending' since transferring isn't
represented at those lower levels.
4. Since SendingArgsAndResults is always enabled when TransferringArgsAndResults
is enabled (NOTE not vis-a-versa), we know that we can always parse sending. So
we import "transferring" as "sending". This means that even if one marks a
function with "transferring", the compiler will guard it behind a
SendingArgsAndResults -D flag and in the imported header print out sending.
rdar://128216574
Add a new demangler option which excludes a closure's type signature.
This will be used in lldb.
Closures are not subject to overloading, and so the signature will never be used to
disambiguate. A demangled closure is uniquely identifiable by its index(s) and parent.
Where opaque types are involved, the concrete type signature can be quite complex. This
demangling option allows callers to avoid printing the underlying complex nested
concrete types.
Example:
before: `closure #1 (Swift.Int) -> () in closure #1 (Swift.Int) -> () in main`
after: `closure #1 in closure #1 in main`
Pavel Yaskevich
Kavon Farvardin
Joe Groff
Tim Kientzle
Erik Eckstein
Michael Gottesman
JanBaig
Slava Pestov
Nate Chandler
Amritpan Kaur
Konrad `ktoso` Malawski
Tony Allevato
Alejandro Alonso
John McCall
Kuba Mracek
Konrad `ktoso` Malawski
Meghana Gupta
Alex Hoppen
Mykola Pokhylets
Akira Hatanaka
Dave Lee
Alastair Houghton