Skip to content

Conversation

@QuietMisdreavus
Copy link
Contributor

Bug/issue #, if applicable: rdar://150207195

Summary

The link resolver emits diagnostics for symbol links that require a disambiguation suffix (or a more precise suffix) to resolve to a single symbol. The diagnostic also includes fix-it solutions suggesting the available suffixes for the conflicting symbols. However, the logic for reporting the ranges of these possible replacements has a flaw when reporting on a curated symbol link: it always uses the full name of the symbol as the base instead of the written symbol or just the suffix.

This PR updates the diagnostic logic to handle the case of a found disambiguation suffix separately when reporting the diagnostic solutions.

Dependencies

None

Testing

The functionality is difficult to test outside of a unit test environment, as it requires non-overloadable symbols to have conflicting names. This is primarily only going to happen with errors in symbol graph generation that cause separate sets of symbols to exist. Nonetheless, the unit test captures the behavior.

Checklist

Make sure you check off the following items. If they cannot be completed, provide a reason.

  • Added tests
  • Ran the ./bin/test script and it succeeded
  • [ n/a ] Updated documentation if necessary

@QuietMisdreavus
Copy link
Contributor Author

@swift-ci Please test

Copy link
Contributor

@d-ronnqvist d-ronnqvist left a comment

Choose a reason for hiding this comment

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

Looks good to me. Just one question and some minor non-blocking comments on the test.

let nextPathComponent = remaining.first!
let (pathPrefix, _, solutions) = makeCollisionSolutions(from: collisions, nextPathComponent: nextPathComponent, partialResultPrefix: partialResult.pathPrefix)

let (pathPrefix, foundDisambiguation, solutions) = makeCollisionSolutions(
Copy link
Contributor

Choose a reason for hiding this comment

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

question: Is .lookupCollision the only kind of value where this happened or should we add similar checks to the other types of errors as well?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It looks like the rangeAdjustment feature is also used by the unknownDisambiguation and unknownName errors, which could also potentially be wrong. Would you like me to investigate these options in this PR, or land this as-is and investigate those later?

Copy link
Contributor

Choose a reason for hiding this comment

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

Either way works. If it's easy to investigate and fix it might make sense to do it while all of this is fresh in the mind.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I added tests for those cases to see if they would also have problems, and it looks like they're fine. 🤷‍♀️ I'll leave the tests in for posterity, but i didn't need to change anything for the cases i tested.

@QuietMisdreavus QuietMisdreavus force-pushed the collision-range-adjustment branch from 24b8f9b to a7b2a37 Compare May 8, 2025 23:06
@QuietMisdreavus
Copy link
Contributor Author

@swift-ci Please test

@QuietMisdreavus QuietMisdreavus merged commit b14b0d9 into swiftlang:main May 9, 2025
2 checks passed
@QuietMisdreavus QuietMisdreavus deleted the collision-range-adjustment branch May 9, 2025 15:58
QuietMisdreavus added a commit to QuietMisdreavus/swift-docc that referenced this pull request May 9, 2025
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