================
@@ -214,11 +214,11 @@ int \N{Λ} = 0;
// expected-error@-2 {{expected unqualified-id}}
const char* emoji = "\N{🤡}";
// expected-error@-1 {{'🤡' is not a valid Unicode character name}}
-// expected-note@-2 {{did you mean OX ('🐂' U+1F402)?}}
-// expected-note@-3 {{did you mean ANT ('🐜' U+1F41C)?}}
-// expected-note@-4 {{did you mean ARC ('⌒' U+2312)?}}
-// expected-note@-5 {{did you mean AXE ('🪓' U+1FA93)?}}
-// expected-note@-6 {{did you mean BAT ('🦇' U+1F987)?}}
+// expected-note@-2 {{did you mean BS (U+0008)?}}
+// expected-note@-3 {{did you mean CR (U+000D)?}}
+// expected-note@-4 {{did you mean EM (U+0019)?}}
+// expected-note@-5 {{did you mean FF (U+000C)?}}
+// expected-note@-6 {{did you mean FS (U+001C)?}}
----------------
eisenwave wrote:
> if the name of the codepoint contains non-ascii characters we should just not
> offer any suggestion at all.
That would just mean that you don't get suggestions when you put an emoji or
something else nonsensical in `\N{}`, but it doesn't solve the issue of `\N{B}`
suggesting `\N{BS}`.
I honestly still don't see the problem though. If you type `\N{NIL}`, I think
`\N{NUL}` is a perfectly fine suggestion, but whatever. If you type a long name
like `\N{DIGIT ZRO}`, you're not going to get a suggestion for these 2-4 letter
abbreviations anyway, so what problem are we actually trying to fix here?
And what was the example with a clown emoji within `\N` ever supposed to
demonstrate? No one will every expect that to work, so you're unhappy with a
garbage example producing garbage results 🤷
That being said, I can still add a filter for abbreviations (perhaps by just
creating a `char32[]` plus binary search), but this all feels a bit pointless.
https://github.com/llvm/llvm-project/pull/203944
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
