Skip to content

Raw identifiers for suite types aren't treated as display names #1104

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
Open
grynspan opened this issue May 4, 2025 · 0 comments · May be fixed by #1105
Open

Raw identifiers for suite types aren't treated as display names #1104

grynspan opened this issue May 4, 2025 · 0 comments · May be fixed by #1105
Assignees
@grynspan
Labels
bug 🪲 Something isn't working discovery 🔎 test content discovery macros 🔭 Related to Swift macros such as @Test or #expect
Milestone
Swift 6.x

Comments

@grynspan
Copy link
Contributor

grynspan commented May 4, 2025 •
edited
Loading

Run the following code:

import Testing

struct `My example tests` {
    @Test func `one little test`() {}
    @Test func `and/another/one`() {}
}

The test functions are correctly treated as having display names, but the suite is not. Because it doesn't have @Suite, its name is inferred at runtime instead of at compile time. Adding @Suite correctly infers the name.

This should be a mostly trivial fix: if the name of the type is a raw identifier and the suite is synthesized, treat the type name as the suite's display name.

There's an edge case here where backticks are used for names that are not raw (e.g. struct `notraw`), but we would need to pull in swift-syntax at runtime to detect those. We can change the rules here and simply infer that any use of backticks around a type or function name produces a display name (but won't produce the diagnostic we get when you also specify a display name with a string literal, because it might be necessary in that case I guess.) No there isn't, because such names won't have backticks when demangled. So we're fine.
@grynspan grynspan added bug 🪲 Something isn't working discovery 🔎 test content discovery macros 🔭 Related to Swift macros such as @Test or #expect labels May 4, 2025
@grynspan grynspan added this to the Swift 6.x milestone May 4, 2025
@grynspan grynspan self-assigned this May 4, 2025
grynspan added a commit that referenced this issue May 4, 2025
@grynspan
Synthesize display names for de facto suites with raw identifiers.
0059b5d 
This PR ensures that suite types that don't have the `@Suite` attribute but which _do_ have raw identifiers for names are correctly given display names the same way those with `@Suite` would be. This PR also ensures that we transform spaces in raw identifiers after they are demangled by the runtime--namely, the runtime replaces ASCII spaces (as typed by the user) with Unicode non-breaking spaces (which aren't otherwise valid in raw identifers) in order to avoid issues with existing uses of spaces in demangled names. We want to make sure that identifiers as presented to the user match what the user has typed, so we need to transform these spaces back. No changes in this area are needed for display names derived during macro expansion because we do the relevant work based on the source text which still has the original ASCII spaces.

This PR also deletes the "raw$" hack that I put in place when originally implementing raw identifier support as the entire toolchain supports them now.

Resolves #1104.
@grynspan grynspan linked a pull request May 4, 2025 that will close this issue
Open
2 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@grynspan grynspan

Labels
bug 🪲 Something isn't working discovery 🔎 test content discovery macros 🔭 Related to Swift macros such as @Test or #expect
Projects
None yet
Milestone
Swift 6.x
Development

Successfully merging a pull request may close this issue.

Synthesize display names for de facto suites with raw identifiers. swiftlang/swift-testing
1 participant
@grynspan