Skip to content
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

[SR-6787] Unexpected result when getting a String describing a type created inside a function #49336

Closed
swift-ci opened this issue Jan 18, 2018 · 9 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. good first issue Good for newcomers standard library Area: Standard library umbrella

Comments

@swift-ci
Copy link
Collaborator

Previous ID SR-6787
Radar None
Original Reporter dreymonde (JIRA User)
Type Bug
Status Resolved
Resolution Done
Environment

Apple Swift version 4.0.3 (swiftlang-900.0.74.1 clang-900.0.39.2)

Target: x86_64-apple-macosx10.9

Additional Detail from JIRA
Votes 0
Component/s Standard Library
Labels Bug, StarterBug
Assignee dreymonde (JIRA)
Priority Medium

md5: 8c7915ab890e09c28c37e2e83c70c057

relates to:

  • SR-6032 String(describing:) shouldn't include extra stuff if the class is private

Issue Description:

When a type is declared inside a function (or a closure), trying to get String describing a type of its instance unexpectedly returns a String with weird « #1» addition.

class TestA { }
let a = TestA()
print(String(describing: type(of: a))) // TestA

func testB() {
    class TestB { }
    let b = TestB()
    print(String(describing: type(of: b))) // TestB #​1
}

testB()

When trying to get String(reflecting🙂, it returns

TestB #​1 in WrongTypeName.testB() -> ()

Which gives a little insight to what’s going on.

@belkadan
Copy link
Contributor

Hm, I'm inclined to agree that the simple demangling shouldn't include the local discriminator, even though the name won't be unique. (It already doesn't include private discriminators, I believe.) @rjmccall, @eeckstein, what do you think?

@eeckstein
Copy link
Member

I agree. This makes sense for local types. The simplified demangling is ambiguous anyway.

Although we should keep the #-numbering for closures, because it's not uncommon to have multiple closures in the same function.

@belkadan
Copy link
Contributor

Good call. Okay, I'm going to mark this as a Starter Bug because the fix will look a lot like SR-6032.

@swift-ci
Copy link
Collaborator Author

swift-ci commented Feb 5, 2018

Comment by Timur Islamgulov (JIRA)

It looks like behaviour has been changed. Given snippet produces the following output:

TestA
TestB

And print(String(reflecting: type(of: b))) prints:

String.(unknown context at 0x100001eec).TestB

If I'm not mistaken, this is where new behaviour has been introduced.

@belkadan
Copy link
Contributor

belkadan commented Feb 5, 2018

:-( @jckarter, you've regressed printing of local types. Want a separate bug for that?

@jckarter
Copy link
Member

jckarter commented Feb 5, 2018

I changed it intentionally. The new presentation is unambiguous and allows for eventual anonymization of type metadata.

@jckarter
Copy link
Member

jckarter commented Feb 5, 2018

Sorry i didn't see this bug sooner. String(describing:) should now work in the way desired in the bug report, since it'll print the unqualified local type name without a discriminator now.

@belkadan
Copy link
Contributor

belkadan commented Feb 5, 2018

Uh, hm. Previously you could use the printed representation for debugging purposes to get back to where the type was declared. Is that not interesting anymore?

(I know, I know, normally I'm the secrecy one, but I'm coming around to the idea that it'll be opt-in.)

@jckarter
Copy link
Member

jckarter commented Feb 5, 2018

With the new context descriptor format, we do have some flexibility to decide how much context information we preserve at runtime. We could generate nested AnonymousContextDescriptor s for nested contexts. I could add back an optional Name field for anonymous contexts too if we think that's useful.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. good first issue Good for newcomers standard library Area: Standard library umbrella
Projects
None yet
Development

No branches or pull requests

4 participants