Interface IIncludePathCanonicalizer

Namespace: ShadowDusk.Core.Preprocessor

Assembly: ShadowDusk.Core.dll

Reports the spelling a resolved #include path actually has on the storage it came from, so the preprocessor can decide whether two differently-cased paths name the same file by asking rather than by guessing from the operating system.

public interface IIncludePathCanonicalizer

Remarks

The preprocessor keys its cycle-detection stack and its #pragma once set on resolved paths, so it needs to know when Shared/Common.fxh and shared/common.fxh are one file and when they are two. Inferring that from the host OS is wrong in both directions: Android's file system is case-sensitive (it is Linux), and APFS can be formatted case-sensitive, so "not Linux ⇒ case-insensitive" merges two genuinely distinct headers; conversely a case-insensitive volume mounted on Linux, or a per-directory case-sensitive NTFS directory on Windows, breaks the opposite assumption.

Canonicalizing sidesteps the question entirely: on a case-insensitive volume both spellings canonicalize to the one name on disk (so they compare equal), and on a case-sensitive volume each spelling canonicalizes to itself (so they compare distinct). No OS check is involved, and the answer is right on a host nobody has tested on.

This is an interface so a unit test can drive both file-system behaviours without a disk, and so an IIncludeResolver serving a virtual file set can describe its own naming rules.

Methods

TryGetOnDiskPath(string)

Returns path re-spelled exactly as the storage holding it spells it, or null when that cannot be determined (the path does not exist, it is a virtual name with no backing store, or the lookup failed).

string? TryGetOnDiskPath(string path)

Parameters

path string: A resolved path, as produced by an IIncludeResolver.

Returns