Menu ▾ ▴

#576 Project Dependencies: the unit name lookup does not resolve names the way the compiler does

New
open
nobody
None
21 hours ago
21 hours ago
No

With the fix for [#574], Project Dependencies (with "Search Library Path" on) looks up a unit that the project file uses without an "in" clause as <Unit>.pas, then as <Scope>.<Unit>.pas for each of the project's unit scope names (TfmProjDepend.TryFindUnitSource in GX_ProjDepend.pas). The compiler resolves unit names in more ways, which the lookup does not follow:

  • The project's default namespace: Ota.GetProjectNamespaces returns it, but it is not tried.
  • The project's own namespace: Ota.GetProjectNamespaces works out the part of a dotted project name before the first dot (ProjectNS), but then adds the whole project name to the list. For My.App.dpr it tries My.App.Utils.pas, not My.Utils.pas.
  • Unit aliases from the project options, e.g. WinTypes=Winapi.Windows (Ota.GetUnitAliases).
  • Names written differently in different units are not linked. A unit found by the search is listed under the name the project file uses, e.g. SysUtils, so a unit that writes System.SysUtils is not connected to it. Resolving every name in the uses lists to its full name would fix that.

Whether and in which order the compiler uses the default namespace and the project's namespace has to be checked first.

The loop that tries a name with each unit scope name exists three times, in Project Dependencies (TryFindUnitSource), the Uses Clause Manager ("Add Unit Prefixes", GX_UsesExpert.pas) and Declare Variable (GX_eDeclareVariable.pas), and they treat the default namespace differently. One shared helper in GX_OtaUtils.pas would keep the rules in one place.

Found in the review of the fix for [#574].

Related

Bugs: #574

Discussion


Log in to post a comment.