Type inference for character literals (and HIGHCHARUNICODE handling)

[zaneduffield]

Prerequisites

• This improvement has not already been suggested.
• This improvement would be generally useful, not specific to my code or setup.

Engine area

Delphi language support

Improvement description

Related to #116 is the problem of type inference of character literals.

The page on the HIGHCHARUNICODE directive provides a pretty good explanation of how it's supposed to work

The {$HIGHCHARUNICODE ON} directive controls the behavior of characters #$80 ... #$FF (#⁠128 ... #⁠255).

When HIGHCHARUNICODE is OFF:

• All decimal #xxx n-digit literals are parsed as AnsiChar.
• All hexadecimal #$xx 2-digit literals are parsed as AnsiChar.
• All hexadecimal #$xxxx 4-digit literals are parsed as WideChar.

When HIGHCHARUNICODE is ON:

• All literals are parsed as WideChar.

This tells us that the type of a character literal depends both on its value and the state of the HIGHCHARUNICODE directive.

Here's a short example that illustrates how this could make a difference to analysis

{$HIGHCHARUNICODE OFF}

procedure Foo(a: AnsiChar); overload;
begin
end;

procedure Foo(a: WideChar); overload;
begin
end;

begin
  Foo(#128); // calls Foo(AnsiChar) (when HIGHCHARUNICODE is OFF)
  Foo(#127); // calls Foo(WideChar)
end.

Rationale

As in #116, this is required for fully accurate type resolution.

[cirras]

Well, we're surely not getting this right at the moment. On unicode versions of Delphi, we're always interpreting character literals as WideChar. Adding support for HIGHCHARUNICODE shouldn't be too tricky, for that upper ANSI range we'll just need to check the switch registry and see if it's active when creating the type for the expression node.