Grapheme cluster breaking in the compiler for diagnostic printing

[SDGGiesbrecht (Jeremy David Giesbrecht)]

@owenv

It sounds like the best time to tackle better compile-time Unicode support will be once the standard library has successfully dropped the ICU dependency, since we can hopefully reuse some of that work.

Yup. There are a lot of things piling up behind that bottleneck:

ICU usage in Swift

I asked about the status of ICU (or whatever standin) in the compiler itself over in another thread and still have no answer. Maybe someone here knows? While I realize the compiler and the standard library are distinct, I am not sure how much their dependency requirements affect each other. Anyone working on this should probably be aware that access to some form of Unicode normalization will be required for the other.

---

What exactly is it you need “columns” for?

Is this about reporting numbers that other tools will use to find the locations of errors? (Then just use UTF‐8 byte counts for simplicity.)

Or is it about getting the caret in the right place on the next line for things like this?

hello.swift:2:5: error: invalid redeclaration of 'y'
  1| let y = 0
   |     ^ note: 'y' previously declared here 
  2| var y = 0
         ^

If that is what you are aiming for, then there really is no solution, because the whole concept of monospace crashes and burns when you venture beyond ASCII. I would advise completely rethinking how the information is presented instead, and find a way to clearly highlight the range inline. Maybe for terminals it could use colours or underlining. Where colours aren’t available, you could enclose it in ornamental brackets of some kind. Or you could borrow from the Venda language and stick a low combining circumflex directly onto the character (◌̭ U+032D). The point is, if you make it stand out inline, then you do not need column offsets at all.