Skip to content

Add an opt-in flag to enforce (printable) ASCII only string literals #41365

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

Closed

Conversation

kubamracek
Copy link
Contributor

The primary motivation is that this flag, -string-literals-must-be-ascii-only, is to be used for the 'freestanding' stdlib which is compiling without Unicode data tables -- see #40573 and #41258 -- or for other use cases where full Unicode string support is not desired. In those cases, it's nice to have a compile time proof that there's no string literals used in the source code that would require these Unicode data tables and therefore would crash at runtime.

@kubamracek
Copy link
Contributor Author

@swift-ci please test

@kubamracek kubamracek force-pushed the ascii-only-string-literals branch from eb2709b to 78f97fd Compare February 14, 2022 18:13
@kubamracek
Copy link
Contributor Author

@swift-ci please test

@karwa
Copy link
Contributor

karwa commented Feb 15, 2022

Would be nice to have tests for:

  • Multi-line ASCII strings
  • ASCII string with a null byte (allowed, I believe)
  • String with a unicode character after a null byte (to check the unicode character is detected and disallowed)

@kubamracek kubamracek force-pushed the ascii-only-string-literals branch from 78f97fd to d3b4f2e Compare February 15, 2022 14:51
@kubamracek
Copy link
Contributor Author

@karwa Added.

@kubamracek
Copy link
Contributor Author

@swift-ci please test

@kubamracek
Copy link
Contributor Author

@swift-ci please test macOS platform

@NSAntoine
Copy link
Contributor

@kubamracek would it be a good idea to include the non-ASCII string in the error message?

@kubamracek
Copy link
Contributor Author

I've had some detailed offline discussions about this with Joe, and I think there are aspects that I haven't considered, specifically that string literals in source code don't necessarily need to always be Swift.String types (because of ExpressibleByStringLiteral), but there's more aspects of the not-full-Unicode-supporting stdlib variant. I'm going to put this PR on ice for now, perhaps coming back to it later.

@kubamracek kubamracek closed this Feb 18, 2022
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.

5 participants