[server] fix false module shadowing across packages#12938
Conversation
check_module_shadowing built the candidate shadow path from the module's short name only (dir/<name>.hx), ignoring its package. So a changed directory containing a same-short-named file in a *different* package would falsely shadow a packaged module, marking it dirty on every build and cascading to its whole dependency cone. Only treat a changed directory as a shadow source for a module when the directory is that module's package directory (its path ends with the module's package). Root-package modules keep the previous behavior; legitimate shadowing (incl. _std overrides) is unaffected.
|
Unfortunately I don't think that's technically correct because Haxe's imports still have that odd parent package browsing Nicolas implemented 20 years ago. If you're in module However, there's definitely an improvement potential because #9150 has been addressed by now, which was part of the reason why the shadowing check is so conservative. |
|
I know but this change should only be about making a shadowed module dirty, it shouldn't get in the way of parent package browsing? (and if it did, it would likely have exploded on me already?) Edit: hmm, I think I see what you're saying; will need to double check if that is using the "real" package for the module, and not just the name used to resolve to it |
The previous fix restricted the shadow scan to the module's *exact* package directory, which is unsound under Haxe's parent-package browsing: from a.b.X an unqualified R resolves a.b.R > a.R > R, so a newly created deeper a.b.R shadows the cached a.R for references made from a.b. Requiring the changed dir to equal the module's package dir misses that and leaves dependents bound to the stale shallower module. Match instead when the module's package is a *prefix* of the changed dir's package (the package dir itself or any sub-package of it). Tested textually (prefix at path start or as a "/"-delimited sub-path) rather than by classpath-root stripping, so a path-normalization mismatch can't become a missed shadow; the only residual is a rare harmless over-invalidation when a same-named package is nested under another.
2 participants
check_module_shadowingbuilt the candidate shadow path from the module's short name only (dir/<name>.hx), ignoring its package. So a changed directory containing a same-short-named file in a different package would falsely shadow a packaged module, marking it dirty on every build and cascading to its whole dependency cone.Only treat a changed directory as a shadow source for a module when the directory is that module's package directory (its path ends with the module's package). Root-package modules keep the previous behavior; legitimate shadowing (incl.
_stdoverrides) is unaffected.