FWD » Core Development » Conversion Tools

Danut, I looked at the changes in 11156a. They look right to me. But I wonder one thing: doesn't it affect the portability? In other words, I see many absolutePath being used, but if these paths reach some artifacts (including H2 incremental conversion database), won't this mean that the project should be converted always in the same place.

• As a regression test, can you convert a project at a patch, move the project somewhere else and run incremental conversion?
• Also think of OO and other more peculiar cases where conversion paths may end up being saved in artifacts / H2 database.
• Also consider Windows system for regression testing these changes.
• Nevertheless, mind that conversion is also being used at run-time, so double-check that there is no security backdoor into these changes done now (like converting a query that does some .., /etc logic).

AI review:

• [MAJOR] functional SymbolResolver.exists: The exact-case branch now returns file.getAbsolutePath() (symlink preserved), but the case-insensitive fallback still calls FileSystemDaemon.getCaseInsensitiveMatch(file, true), which canonicalizes both input and result and therefore resolves symlinks. pkgExists always calls exists(file, false) for PROPATH entries (4GL class matching is case-insensitive), so on Linux any case-mismatched package reference reaches the fallback regardless of the case-sensitive setting. With a symlinked package directory under basepath (e.g. abl/lib -> /elsewhere/shared), USING lib.util.* normalizes to ./lib/util, while USING Lib.Util.* yields the canonical /elsewhere/shared/util. normalizeFilename cannot relativize that path, even with its canonical fallback, so the USING handling writes normalized-path=.elsewhere.shared.util. oo_references.rules then drops the Java import or builds a wrong package name. Trunk was uniformly canonical, so this branch leaves the result dependent on the letter case of the reference, which defeats its symlink-preserving goal. The case-insensitive path needs the same non-canonical treatment: match against the absolute/normalized path and return getAbsolutePath().
• [MAJOR] functional FileScope.resolveFileName: On a Windows conversion host, getCanonicalPath() used to fold a path to its on-disk case. getAbsolutePath() / Path.normalize() now keep the case as referenced. Because NTFS is case-insensitive, two references differing only in case (e.g. {Inc/X.i} and {inc/x.i}) both pass the first canRead(), and findCaseInsensitively is never reached. open then sets fileName = normalizeFilename(fullname), producing ./Inc/X.i and ./inc/x.i. Since ArtifactKey compares names with plain String.equals / hashCode, one file becomes two artifacts. This splits pphints, include dependency tracking and AST registration. The same applies to class/package paths from SymbolResolver.exists, to the AST artifact names in AstGenerator, and to the case of the &{FILE_NAME} output. Linux hosts are unaffected. Windows conversion is explicitly supported (CallGraphHelper.isWindowsOs).
• [MINOR] functional ArtifactManager.normalizeFilename: .. segments are now collapsed lexically by Path.normalize(), while the file itself is still opened through the raw path, where the OS resolves .. physically. Example: propath entry ./abl/app, where abl/app is a symlink to /x/app, and an include {../common/x.i}. FileScope.resolveFileName builds /proj/./abl/app/../common/x.i, and open reads /x/common/x.i. The registered key, however, becomes ./abl/common/x.i, which lies under home, so the canonical fallback never runs. That key feeds the ClearStream IncludeHint artifact, &{FILE_NAME}, the CallGraphWorker findUniqueNode lookup (which creates a phantom node for a non-existent path) and loadIncludeHints, all of which point at a missing or different file. Trunk's realpath kept the key consistent with the file actually read.

Style review is omitted for brevity. Regenerate the review yourself to capture the styling issues after we finish the functional bullets.