Skip to content

TypeDecoder: Push one-element tuple unwrapping down into createTupleType() implementations [5.9] #67936

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.

Sign up for GitHub

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

Jump to bottom
Merged
merged 1 commit into from
Aug 16, 2023
Merged

TypeDecoder: Push one-element tuple unwrapping down into createTupleType() implementations [5.9] #67936

merged 1 commit into from
Aug 16, 2023

Conversation

slavapestov
Copy link
Contributor

@slavapestov slavapestov commented Aug 15, 2023 •
edited
Loading

  • Description: LLDB's Type reconstruction would incorrectly unwrap one-element tuples containing pack expansions. This was because the unwrapping was added in the wrong place. Move it to the implementations where we have the right information to decide if we should unwrap or not.
  • Origination: A regression from TypeDecoder: Unwrap unlabeled one-element tuples when expanding pack expansions #67180 which was cherry-picked into 5.9
  • Scope of the issue: Caught by the round-trip verifier in assert builds.
  • Risk: Low, this only has a functional effect in the type reconstruction case, since the other clients unconditionally unwrap.
  • Tested: Added more test cases to exercise round-trip type reconstruction.
  • Reviewed by: @hborla
  • Issue: Compiler crash with pack expansion #67322
  • Radar: rdar://113595455

@slavapestov
TypeDecoder: Push one-element tuple unwrapping down into createTupleT…
b6d32c0 
…ype() implementations

The old behavior was only correct when building substituted types,
ie, if createTupleType() was never called with a pack expansion type.

This was the case in the runtime's MetadataLookup which applies
substitutions to an interface type to ultimately construct metadata
for a fully-concrete type, but not in the ASTDemangler, where we
actually build interface types.

Since TypeDecoder doesn't have any way to query the kind of type
it just built, let's just instead make this decision inside the
implementation of the type builder concept.

Fixes swiftlang#67322.
@slavapestov slavapestov requested a review from a team as a code owner August 15, 2023 16:05
@slavapestov
Copy link
Contributor Author

@swift-ci Please smoke test

@slavapestov
Copy link
Contributor Author

@swift-ci Please test

@slavapestov slavapestov merged commit 35051fd into swiftlang:release/5.9 Aug 16, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@hborla hborla hborla approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@slavapestov @hborla