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

Jump to bottom

[SR-15202] [5.5] Typealias in generic constraint is wrongly ASTPrinted as underlying type #57524

Open
johnfairh opened this issue Sep 16, 2021 · 5 comments
Open

[SR-15202] [5.5] Typealias in generic constraint is wrongly ASTPrinted as underlying type #57524

johnfairh opened this issue Sep 16, 2021 · 5 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior.

Comments

@johnfairh
Copy link
Contributor

Previous ID SR-15202
Radar rdar://83300297
Original Reporter @johnfairh
Type Bug
Status Reopened
Resolution
Environment

Xcode 13.0 RC 13A233 / macOS 12.0 Beta (21A5506j)
swift-driver version: 1.26.9 Apple Swift version 5.5 (swiftlang-1300.0.31.1 clang-1300.0.29.1)
Target: x86_64-apple-macosx12.0

Additional Detail from JIRA
Votes 0
Component/s Source Tooling
Labels Bug
Assignee None
Priority Medium

md5: 3654dbe11933765a9c76b48a06366376

Issue Description:

Bad behavior is new in Swift 5.5.

class Base {}
typealias Alias = Base 
struct S<T> where T: Alias {}

Running S through ASTPrinter even without setting PrintTypeAliasUnderlyingType gives:

struct S<T> where T : Base

This seems to happen only in generic constraints, class Der : Alias {} works fine.

This means SourceKit clients get the 'wrong', ie. not what the user wrote, info in key.fully_annotated_decl, key.doc.full_as_xml etc. Module interface as well.

It's wrong in SymbolGraph too which affects DocC:
Xcode 13 / Swift 5.5

...
      "swiftGenerics": {
        "parameters": [
          {
            "name": "T",
            "index": 0,
            "depth": 0
          }
        ],
        "constraints": [
          {
            "kind": "superclass",
            "lhs": "T",
            "rhs": "Base",
            "rhsPrecise": "s:4ModA4BaseC"
          }
        ]
...
      "declarationFragments": [
        {
          "kind": "keyword",
          "spelling": "struct"
        },
        {
          "kind": "text",
          "spelling": " "
        },
        {
          "kind": "identifier",
          "spelling": "S"
        },
        {
          "kind": "text",
          "spelling": "<"
        },
        {
          "kind": "genericParameter",
          "spelling": "T"
        },
        {
          "kind": "text",
          "spelling": "> "
        },
        {
          "kind": "keyword",
          "spelling": "where"
        },
        {
          "kind": "text",
          "spelling": " "
        },
        {
          "kind": "typeIdentifier",
          "spelling": "T"
        },
        {
          "kind": "text",
          "spelling": " : "
        },
        {
          "kind": "typeIdentifier",
          "spelling": "Base",
          "preciseIdentifier": "s:4ModA4BaseC"
        }
...

Xcode 12 / Swift 5.4

...
      "swiftGenerics": {
        "parameters": [
          {
            "name": "T",
            "index": 0,
            "depth": 0
          }
        ],
        "constraints": [
          {
            "kind": "superclass",
            "lhs": "T",
            "rhs": "Alias"
          }
        ]
...
      "declarationFragments": [
        {
          "kind": "keyword",
          "spelling": "struct"
        },
        {
          "kind": "text",
          "spelling": " "
        },
        {
          "kind": "identifier",
          "spelling": "S"
        },
        {
          "kind": "text",
          "spelling": "<"
        },
        {
          "kind": "genericParameter",
          "spelling": "T"
        },
        {
          "kind": "text",
          "spelling": "> "
        },
        {
          "kind": "keyword",
          "spelling": "where"
        },
        {
          "kind": "text",
          "spelling": " "
        },
        {
          "kind": "typeIdentifier",
          "spelling": "T",
          "preciseIdentifier": "s:4ModA1SV1Txmfp"
        },
        {
          "kind": "text",
          "spelling": " : "
        },
        {
          "kind": "typeIdentifier",
          "spelling": "Alias",
          "preciseIdentifier": "s:4ModA5Aliasa"
        }

...

I had a quick look through the change history for ASTPrinter, my very wild shot in the dark is maybe fallout from PR 36784 - @ahoppen could you take a quick look when you have a chance?
@ahoppen
Copy link
Contributor

ahoppen commented Sep 20, 2021

Thanks for reporting the bug, John. I’ll take a look at it when I get the chance.

@ahoppen
Copy link
Contributor

ahoppen commented Sep 24, 2021

Doing some debugging, this seems to have been caused by @slavapestov PR#37157, specifically by canonicalizing the RHS type of an ExplicitRequirement here.

@slavapestov
Copy link
Member

I don't think we can guarantee sugared types round-trip through the GenericSignatureBuilder. They certainly don't at all with the new RequirementMachine implementation, where everything is canonicalized.

@johnfairh
Copy link
Contributor Author

Thanks for the investigation. While the astprinter has always done some normalization (eg. whitespace, nested type references,) replacing a type the developer wrote with something they explicitly didn't want their users to read feels to me like a step too far. i guess cc. @bitjammer just so the symbolgraph -> DocC / Quick Help people are aware.

@ahoppen
Copy link
Contributor

ahoppen commented Oct 14, 2021

I still think this is an issue but not one we can easily fix in the short term. Reopening to reflect the fact that we’d like to resolve if somehow possible.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@slavapestov @ahoppen @johnfairh