Skip to content

Demangler: Add option to omit closure signatures #73331

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Apr 30, 2024

Conversation

kastiglione
Copy link
Contributor

@kastiglione kastiglione commented Apr 29, 2024

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

@kastiglione kastiglione marked this pull request as draft April 29, 2024 23:01
@kastiglione
Copy link
Contributor Author

@swift-ci smoke test

@kastiglione kastiglione marked this pull request as ready for review April 30, 2024 15:15
@kastiglione
Copy link
Contributor Author

@swift-ci smoke test

@kastiglione kastiglione merged commit c3488c6 into main Apr 30, 2024
3 checks passed
@kastiglione kastiglione deleted the dl/Demangler-Add-option-to-omit-closure-signatures branch April 30, 2024 19:48
kastiglione added a commit that referenced this pull request Apr 30, 2024
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`
kastiglione added a commit that referenced this pull request May 1, 2024
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`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants