sonar.sourceEncoding is not applied to UnitSearchPath

[wdken]

Prerequisites

• This bug is in SonarDelphi, not SonarQube or my Delphi code.
• This bug has not already been reported.

SonarDelphi version

1.18.3

Delphi version

XE5

SonarQube version

26.4

Issue description

When running analysis with SonarDelphi, the encoding specified by sonar.sourceEncoding is not applied to units resolved via UnitSearchPath. As a result, Delphi source files located in UnitSearchPath may be interpreted with an incorrect encoding, leading to parsing errors during analysis.

For example, even when sonar.sourceEncoding=windows-31j is configured, a unit saved in Shift_JIS (Windows‑31J / CP932, Legacy Japanese encoding used on Windows) and referenced through UnitSearchPath is not decoded correctly, causing the analysis to fail.

Steps to reproduce

1. Create the directory:
   d:\source\project1

2. Create a Delphi console project d:\source\project1\Project1.dpr and add the following directory to search path(UnitSearchPath) in the project options:
   d:\source\parent

3. Create the directory:
   d:\source\parent

4. Create a unit file d:\source\parent\Consts.pas. Do not add this file to the project; it must be resolved only via UnitSearchPath.
   Save Consts.pas using Shift_JIS (Windows‑31J / CP932) encoding.

5. Create a sonar-project.properties file to specify sonar.sourceEncoding.

6. Run SonarScanner.

During analysis, a parser error occurs while processing Consts.pas loaded via UnitSearchPath.

Observed error (excerpt):

Error while processing D:\source\parent\Consts.pas
au.com.integradev.delphi.file.DelphiFile$DelphiFileConstructionException: Failed to construct DelphiFile (line 2:8 no viable alternative at input '・ｽC・ｽY')

Caused by: au.com.integradev.delphi.antlr.DelphiParser$ParserException: line 2:8 no viable alternative at input '・ｽC・ｽY'

Caused by: NoViableAltException(199@[])
        at au.com.integradev.delphi.antlr.DelphiParser.fileWithoutImplementation(DelphiParser.java:681)

Minimal Delphi code exhibiting the issue

d:\source\project1\Project1.dpr

program Project1;

{$APPTYPE CONSOLE}

uses
  System.SysUtils,
  Consts;

begin
  WriteLn(SUMMARY);
end.

d:\source\parent\Consts.pas

{
カスタマイズ
}
unit Consts;

interface

const
  SUMMARY = 'sum';

implementation

end.

This file must be saved using Shift_JIS (Windows‑31J / CP932) encoding.(Legacy Japanese encoding used on Windows)
For environments where creating a Shift_JIS file is difficult, the same file is provided as Base64:
ew0Kg0qDWINeg32DQ4NZDQp9DQp1bml0IENvbnN0czsNCg0KaW50ZXJmYWNlDQoNCmNvbnN0DQogIFNVTU1BUlkgPSAnc3VtJzsNCg0KaW1wbGVtZW50YXRpb24NCg0KZW5kLg0K

Example command to restore the file on Windows:

certutil -decode consts_base64.txt Consts.pas

d:\source\project1\sonar-project.properties

sonar.sourceEncoding=windows-31j

D:\source\project1\Project1.dproj

UnitSearchPath is expected to be stored in Project1.dproj as follows (excerpt):

<PropertyGroup Condition="'$(Base)'!=''">  
    <DCC_UnitSearchPath>D:\source\parent;$(DCC_UnitSearchPath)</DCC_UnitSearchPath>  
</PropertyGroup>  

[cirras]

Hi @wdken,
Thanks for the report and helpful reproduction case. This is a real quirk with the way we're handling file encodings at the moment, and something should be done about it.
I'll give it some thought. 🫡