-
Notifications
You must be signed in to change notification settings - Fork 13k
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
Non-ASCII identifiers should be restricted within extern blocks. #83923
Comments
What will something like extern {
fn ö();
} actually link against? This seems like it might be a forward-compatiblity hazard when linking to external code, since the precise mangling/encoding isn't clear |
I think we should just disallow for now; and later check out what C does and match that. |
@crlf0710 do you want to implement this? Should be a simple check in the parser. |
@Manishearth Sure, let me give it a try. |
Implemented in #83936 . |
On the other hand the use of non-ASCII symbol names is already stable through link_name attribute. |
Out of curiosity, I checked how Clang and GCC mangle the symbol: they simply use UTF-8. extern "C" void héllo() {} // Mangle to "h\C3\A9llo"
void hélla() {} // mangle to "?h\C3\A9lla@@YAXXZ" or "_Z6h\C3\A9llav" (Notice how the byte-length encoding in C++ is using the UTF-8 byte count, and not the code point count, as I would expect) |
Yeah I feel like the functionality can be re-added with an FCP without much work, there just needs to be some research on how stable those mangling schemes are around this. |
As for |
Inversely, I've just noticed that despite usage of a properly-ASCII-ed extern {
#[link_name = "cat"]
fn ᓚᘏᗢ();
} 😿 |
It was mentioned in rust-lang/reference#999 that in the original RFC text, there's text that said the
non-ASCII identifiers should be disallowed within extern blocks.
This is a niche use-case and i believe this doesn't need to block stablization. Creating this issue here to track it.
The text was updated successfully, but these errors were encountered: