Fix integer to string conversion when generating code

[grendello]

Fixes: #7939
Context: dotnet/runtime#13363
Context: https://www.unicode.org/charts/PDF/U2200.pdf (page 2)

LLVM IR generator outputs a number of integer values, relying on the
standard ToString() method to convert the value to string. However,
since NET6, this conversion is culture-sensitive and in certain
cultures (list below) it will output the minus sign not as the standard
ASCII 0x2D character but rather as the Unicode 0x2212 (mathematical
operator "minus") character. This breaks LLVM LLC:

llc: environment.arm64-v8a.ll:554:7: error: expected value token
  stderr |                 i32 −1, ; apk_fd

Fix the problem by using invariant culture when converting all
integers and unknown objects to strings. The reason all of them are
converted in this way is to avoid future changes to ICU and/or .NET
to-string conversion that might affect the resulting integer format.

Locales/cultures affected by this issue are as follows:

• (RTL "-") 26 cultures
  • ar
  • ar-001
  • ar-BH
  • ar-DJ
  • ar-EG
  • ar-ER
  • ar-IL
  • ar-IQ
  • ar-JO
  • ar-KM
  • ar-KW
  • ar-LB
  • ar-MR
  • ar-OM
  • ar-PS
  • ar-QA
  • ar-SA
  • ar-SD
  • ar-SO
  • ar-SS
  • ar-SY
  • ar-TD
  • ar-YE
  • sd
  • sd-Arab
  • sd-Arab-PK
• "‎-": 10 cultures
  • ar-AE
  • ar-DZ
  • ar-EH
  • ar-LY
  • ar-MA
  • ar-TN
  • he
  • he-IL
  • ur
  • ur-PK
• (RTL "-"): 3 cultures
  • ckb
  • ckb-IQ
  • ckb-IR
• "−": 38 cultures
  • et
  • et-EE
  • eu
  • eu-ES
  • fi
  • fi-FI
  • fo
  • fo-DK
  • fo-FO
  • gsw
  • gsw-CH
  • gsw-FR
  • gsw-LI
  • hr
  • hr-BA
  • hr-HR
  • ksh
  • ksh-DE
  • lt
  • lt-LT
  • nb
  • nb-NO
  • nb-SJ
  • nn
  • nn-NO
  • no
  • rm
  • rm-CH
  • se
  • se-FI
  • se-NO
  • se-SE
  • sl
  • sl-SI
  • sv
  • sv-AX
  • sv-FI
  • sv-SE
• "‎−": 3 cultures
  • fa
  • fa-AF
  • fa-IR
• "‎-‎": 16 cultures
  • ks
  • ks-Arab
  • ks-Arab-IN
  • lrc
  • lrc-IQ
  • lrc-IR
  • mzn
  • mzn-IR
  • pa-Arab
  • pa-Arab-PK
  • ps
  • ps-AF
  • ps-PK
  • ur-IN
  • uz-Arab
  • uz-Arab-AF

[jonathanpeppers]

Like I did in: dotnet/maui@c40c6e7

Can we add these rules as errors in the .editorconfig?

dotnet_diagnostic.CA1307.severity = error
dotnet_diagnostic.CA1309.severity = error

[grendello]

Like I did in: dotnet/maui@c40c6e7

Can we add these rules as errors in the .editorconfig?

dotnet_diagnostic.CA1307.severity = error
dotnet_diagnostic.CA1309.severity = error

We should definitely do it, but in a separate PR, I think. It's not directly related to this PR.

[jonpryor]

@grendello: I would like a unit test of some form for this. Could we alter one of the existing app build + deploy tests in tests/MSBuildDeviceIntegration to set the locale for the entire build process, including app deploy?

@dellis1972, @jonathanpeppers?

[jonathanpeppers]

For Mac, we could add test of a Release build, using the option to pass the $LANG env var:

https://github.com/xamarin/xamarin-android/blob/59e1e466bcb6739e976f61a65ce14a24bb6e3bf6/src/Xamarin.Android.Build.Tasks/Tests/Xamarin.ProjectTools/Common/ProjectBuilder.cs#L63

But then we'd want to do some equivalent for Windows, too?

[grendello]

@jonpryor Build stage would be sufficient, we don't need to deploy.
@jonathanpeppers I think mac would be enough, after all we can assume we're using the same dotnet version for both, so the ICU behavior will be identical.

[jonathanpeppers]

Windows what I'm reading seems like a system-wide weird setting, someone recommends creating a user to run a process under...

So maybe it's just not worth it, and we make a new test that only runs on Mac.

[jonathanpeppers]

LGTM if the new test passes. 👍

[jonpryor]

Draft commit message:

Fixes: https://github.com/xamarin/xamarin-android/issues/7939

Context: https://github.com/dotnet/runtime/issues/13363
Context: https://www.unicode.org/charts/PDF/U2200.pdf (page 2)
Context: 5271f3e109a2242caa3bd7801dfad9c1683488d7

The LLVM IR generator (5271f3e1) outputs a number of integer values,
relying on the standard `int.ToString()` method to convert the value
to a string.  However, since .NET 6, this conversion is culture-
sensitive and in certain cultures (list below) it will output the
minus sign not as the "standard" ASCII \u002d character `-` but
instead as something else (see complete list below for details).

This breaks LLVM LLC:

	llc: environment.arm64-v8a.ll:554:7: error: expected value token
	  stderr |                 i32 −1, ; apk_fd

Fix the problem by using invariant culture when converting ***all***
integers and unknown objects to strings.  The reason all of them are
converted in this way is to avoid future changes to ICU and/or .NET
to-string conversion that might affect the resulting integer format.

Workaround: export `$LANG` to a locale that uses 0x2D `-` for
negation, e.g. `LANG=C`.

Locales/cultures affected by this issue are as follows:

  * ARABIC LETTER MARK + HYPHEN-MINUS `؜-` (\u061c \u002d): 26 cultures
    * ar
    * ar-001
    * ar-BH
    * ar-DJ
    * ar-EG
    * ar-ER
    * ar-IL
    * ar-IQ
    * ar-JO
    * ar-KM
    * ar-KW
    * ar-LB
    * ar-MR
    * ar-OM
    * ar-PS
    * ar-QA
    * ar-SA
    * ar-SD
    * ar-SO
    * ar-SS
    * ar-SY
    * ar-TD
    * ar-YE
    * sd
    * sd-Arab
    * sd-Arab-PK
  * LEFT-TO-RIGHT MARK + HYPHEN-MINUS `‎-` (\u200e \u002d): 10 cultures
    * ar-AE
    * ar-DZ
    * ar-EH
    * ar-LY
    * ar-MA
    * ar-TN
    * he
    * he-IL
    * ur
    * ur-PK
  * RIGHT-TO-LEFT MARK + HYPHEN-MINUS `‏-` (\u200f \u002d): 3 cultures
    * ckb
    * ckb-IQ
    * ckb-IR
  * MINUS SIGN `−` (\u2212): 38 cultures
    * et
    * et-EE
    * eu
    * eu-ES
    * fi
    * fi-FI
    * fo
    * fo-DK
    * fo-FO
    * gsw
    * gsw-CH
    * gsw-FR
    * gsw-LI
    * hr
    * hr-BA
    * hr-HR
    * ksh
    * ksh-DE
    * lt
    * lt-LT
    * nb
    * nb-NO
    * nb-SJ
    * nn
    * nn-NO
    * no
    * rm
    * rm-CH
    * se
    * se-FI
    * se-NO
    * se-SE
    * sl
    * sl-SI
    * sv
    * sv-AX
    * sv-FI
    * sv-SE
  * LEFT-TO-RIGHT MARK + MINUS SIGN `‎−` (\u200e \u2212): 3 cultures
    * fa
    * fa-AF
    * fa-IR
  * LEFT-TO-RIGHT MARK + HYPHEN-MINUS + LEFT-TO-RIGHT MARK `‎-‎` (\u200e \u002d \u002e): 16 cultures
    * ks
    * ks-Arab
    * ks-Arab-IN
    * lrc
    * lrc-IQ
    * lrc-IR
    * mzn
    * mzn-IR
    * pa-Arab
    * pa-Arab-PK
    * ps
    * ps-AF
    * ps-PK
    * ur-IN
    * uz-Arab
    * uz-Arab-AF

Update `BuildTest2.BuildBasicApplication()` to export
`LANG=sv_SE.UTF-8` as part of the `dotnet build` command to test this
scenario on macOS and Linux.  (This change is ignored on Windows.)

[jonpryor]

@grendello: will my above suggested workaround of LANG=C work? Or would we need LANG=en_US.UTF-8? (Why suggest LANG=C at all? To be ever so slightly less US-centric. Which is probably laughable, but still.)

[grendello]

@jonpryor yes, LANG=C should work fine, as it will be as ASCII-based as en_US.UTF-8 is and should be available on all Unix systems.

[grendello]

@jonpryor the commit message needs to be updated with the full list of affected cultures (see the OP here) and it needs to mention that it's not just one Unicode character, but several, that replace the ASCII hyphen as the "minus" sign.