Skip to content

Runtime: Properly handle demangling nested generic typerefs with symbolic manglings. #15781

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

Conversation

jckarter
Copy link
Contributor

@jckarter jckarter commented Apr 5, 2018

The demangling tree for a symbolic reference doesn't indicate the generic context depth of the referenced type, so we have to form the type metadata from whole cloth without incrementally building up nested types as we do for concrete mangled types. Notice when DecodedMetadataBuilder is passed a context descriptor ref without a parent and directly form the entire type in this case. Fixes rdar://problem/38891999.

Replace this paragraph with a description of your changes and rationale. Provide links to external references/discussions if appropriate.

Resolves SR-NNNN.

…olic manglings.

The demangling tree for a symbolic reference doesn't indicate the generic context depth of the referenced type, so we have to form the type metadata from whole cloth without incrementally building up nested types as we do for concrete mangled types. Notice when DecodedMetadataBuilder is passed a context descriptor ref without a parent and directly form the entire type in this case. Fixes rdar://problem/38891999.
@jckarter
Copy link
Contributor Author

jckarter commented Apr 5, 2018

@swift-ci Please test

Copy link
Member

@DougGregor DougGregor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suppose remote mirrors wand remote AST will need the same kind of fix, but this LGTM for the runtime.

class d {}
struct e<f> {
var constraints: [Int: a<f>.c] = [:]
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another silly case to test is a type nested inside an extension of a generic type that makes one of its generic parameters concrete, or more generally, any constrained extension

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, having a couple levels of generic/non-generic nesting interleaved is great for sussing out bugs in this code. test/Runtime/demangleToMetadata.swift has some examples.

@jckarter
Copy link
Contributor Author

jckarter commented Apr 6, 2018

@DougGregor In those libraries IIRC we resolve symbolic mangling directly into their mangling tree, since there isn't as much performance win to be had preserving the direct pointer to the type descriptor, so I think they should be OK. I'll double check though, thanks for the suggestion!

@jckarter jckarter merged commit 161afd6 into swiftlang:master Apr 6, 2018
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.

3 participants