From:  Tooru Fujisawa <>
Date:  29 Sep 2016 11:07:34 Hong Kong Time

Changes to error reporting function input/output encoding



I'm now doing code cleanup on error reporting APIs, here's the summary:

  * Add ASCII [1], Latin1 [2], and UTF8 [3] variants to following functions:
    * JS_ReportError
    * JS_ReportErrorNumber
    * JS_ReportErrorNumberVA
    * JS_ReportErrorFlagsAndNumber
    * JS_ReportWarning
    (for example JS_ReportErrorASCII, JS_ReportErrorLatin1, JS_ReportErrorUTF8)
  * Replace existing callsites for non-suffix variants with one of them [4]
  * Remove non-suffix variants (that is implicit Latin1 variants) [4]
  * Change internal encoding of error reporting function from UTF-16 to UTF-8 [5]

After patches bug 1302582, bug 1289051, and bug 1295017 landed, we'll have 4 encoding variants for each type of error reporting function: ASCII, Latin1, UTF8, and UC (only some function).
If you're going to add new callsite, please use one of them, depending on the input (format string and parameter) encoding:
  * input is ASCII
    -> ASCII variants
  * input is ASCII and UTF-8
    -> UTF-8 variants
  * input is ASCII and Latin1 encoded with JSAutoByteString
    -> UTF-8 variants, after re-encoding with JSAutoByteString::encodeUtf8
       (once internal encoding becomes UTF-8, UTF8 variants will become faster
        than Latin1 variants)
  * input is ASCII and Latin1 returned by error some function
    -> Latin1 variants
       (this will happen in several places because our error related functions
        generate Latin1 string [6])
  * input is ASCII and random encoding
    -> Latin1 variants
       (Latin1 is safe for unknown encoding
        this will happen in several places because filename/URL are encoded in
        random encoding [7])

I'll land patches that replace existing callsites incrementally, so you'll see some inconsistency for a while.

Thank you for your attention :)