This reverts commit 25985cb764. For now,
we're trying to avoid spurious non-structural changes to the mangling,
so that the /old/ mangling doesn't appear to change. That doesn't mean
no changes at all, but we can save this one for later.
This can show up when trying to generate USRs for a document with
errors in it. This isn't a great answer because the names it generates
aren't unique (there may be more than one nameless entity with the
same type), but it at least generates valid mangled names.
When generating mangled names for purposes other than USRs, nameless
entities are now checked for by an assertion.
The goal here is to make the short demangling as short and readable as possible, also at the cost of omitting some information.
The assumption is that whenever the short demangling is displayed, there is a way for the user to also get the full demangled name if needed.
*) omit <where ...> because it does not give useful information anyway
Deserializer.deserialize<A where ...> () throws -> [A]
--> Deserializer.deserialize<A> () throws -> [A]
*) for multiple specialized functions only emit a single “specialized”
specialized specialized Constructible.create(A.Element) -> Constructible<A>
--> specialized Constructible.create(A.Element) -> Constructible<A>
*) Don’t print function argument types:
foo(Int, Double, named: Int)
--> foo(_:_:named:)
This is a trade-off, because it can lead to ambiguity if there are overloads with different types.
*) make contexts of closures, local functions, etc. more readable by using “<a> in <b>” syntax
This is also done for the full and not only for the simplified demangling.
Renderer.(renderInlines([Inline]) -> String).(closure #1)
--> closure #1 in Renderer.renderInlines
*) change spacing, so that it matches our coding style:
foo <A> (x : A)
--> foo<A>(x: A)
There are cases where the re-mangling doesn't yield the original mangled name.
This is no problem for the compiler as it only affects how mangling substitutions are handled.
rdar://problem/31539542
Replace VariadicTuple and NonVariadicTuple with a single Tuple node.
The variadic property is now part of the tuple element and not of the whole tuple.
Instead of appending a character for each substitution, we now prefix the substitution with the repeat count, e.g.
AbbbbB -> A5B
The same is done for known-type substitutions, e.g.
SiSiSi -> S3i
This significantly shrinks mangled names which contain large lists of the same type, like
func foo(_ x: (Int, Int, Int, Int, Int, Int, Int, Int, Int, Int, Int, Int))
rdar://problem/30707433
The actual problem is that the mangling is wrong. But it’s hard to fix now and we will switch to the new mangling anyway.
So this fix just makes sure the demangler (and therefore lldb) does not crash.
fixes rdar://problem/29881277
Local generic types can appear inside functions inside extensions
of other types. When demangling bound generic arguments, the demangler
assumed that a module was the only other kind of context outside
of nominal types.
rdar://problem/27573079
* Add UnsafeRawPointer type and API.
As proposed in SE-0107: UnsafeRawPointer.
https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md
The fundamental difference between Unsafe[Mutable]RawPointer and
Unsafe[Mutable]Pointer<Pointee> is simply that the former is used for "untyped"
memory access, and the later is used for "typed" memory access. Let's refer to
these as "raw pointers" and "typed pointers". Because operations on raw pointers
access untyped memory, the compiler cannot make assumptions about the underlying
type of memory and must be conservative. With operations on typed pointers, the
compiler may make strict assumptions about the type of the underlying memory,
which allows more aggressive optimization.
Memory can only be accessed by a typed pointer when it is currently
bound to the Pointee type. Memory can be bound to type `T` via:
- `UnsafePointer<T>.allocate(capacity: n)`
- `UnsafePointer<Pointee>.withMemoryRebound(to: T.self, capacity: n) {...}`
- `UnsafeMutableRawPointer.initializeMemory(as: T.self, at: i, count: n, to: x)`
- `UnsafeMutableRawPointer.initializeMemory(as: T.self, from: p, count: n)`
- `UnsafeMutableRawPointer.moveInitializeMemory(as: T.self, from: p, count: n)`
- `UnsafeMutableRawPointer.bindMemory(to: T.self, capacity: n)`
Mangle UnsafeRawPointer as predefined substitution 'Sv' for Swift void
pointer ([urp] are taken).
* UnsafeRawPointer minor improvements.
Incorporate Dmitri's feedback.
Properly use a _memmove helper.
Add load/storeBytes alignment precondition checks.
Reword comments.
Demangler tests.
* Fix name mangling test cases.
* Fix bind_memory specialization.
- All parts of the compiler now use ‘P1 & P2’ syntax
- The demangler and AST printer wrap the composition in parens if it is
in a metatype lookup
- IRGen mangles compositions differently
- “protocol<>” is now “swift.Any”
- “protocol<_TP1P,_TP1Q>” is now “_TP1P&_TP1Q”
- Tests cases are updated and added to test the new syntax and mangling
Change the 'G' mangling to include generic parameters from
all levels of nested nominal types, and not just the innermost.
Note that the raw mangling syntax is something like this for
a nested type 'A<Int>.B<String>':
- bound_generic
- struct 'B'
- struct 'A'
- module 'M'
- args
- Int
- args
- String
However, the actual mangling tree is more along the lines of:
- bound_generic_struct 'B'
- bound_generic_struct 'A'
- module 'M'
- args
- Int
- args
- String
This arrangement improves the quality of substitutions (we are
more likely to have a substitution for the entire unbound
generic type name 'A.B' around), and simplifies a few other
details.
Unfortunately, the remangling logic becomes slightly grotesque.
A simple SILGen test for nested generics exercises the mangling,
and ensures that Sema and SILGen do not crash with nested generics.
More detailed SILGen tests, as well as IRGen support for nested
generics is next.
These are really long and don't tell you anything interesting
in backtraces. They can also take up quite a bit of valuable
real estate in vertical layouts.
rdar://problem/22982415
An upcoming change has the SIL Optimizer drop the [fragile]
attribute from the specialized callee, unless the caller
is itself [fragile].
Since we need to distinguish specializations from fragile
and non-fragile contexts, add a new mangling node to
represent this concept.
...by mangling them the same as any other value decl. This is important for debug info to
preserve and recover a private typealias.
rdar://problem/24921067
Make it clear that this is not a nested type or submodule or anything.
Mangled: _TFE9ExtModuleV9DefModule1A4testfT_T_
Before: ext.ExtModule.DefModule.A.test () -> ()
After: (extension in ExtModule):DefModule.A.test () -> ()
of associated types in protocol witness tables.
We use the global access functions when the result isn't
dependent, and a simple accessor when the result can be cheaply
recovered from the conforming metadata. Otherwise, we add a
cache slot to a private section of the witness table, forcing
an instantiation per conformance. Like generic type metadata,
concrete instantiations of generic conformances are memoized.
There's a fair amount of code in this patch that can't be
dynamically tested at the moment because of the widespread
reliance on recursive expansion of archetypes / dependent
types. That's something we're now theoretically in a position
to change, and as we do so, we'll test more of this code.
This speculatively re-applies 7576a91009,
i.e. reverts commit 11ab3d537f.
We have not been able to duplicate the build failure in
independent testing; it might have been spurious or unrelated.
