Fix Issue 7016 - local import does not create -deps dependency

[RazvanN7]

Semantic3 wasn't called on module dependencies, so I added a function which recursively calls it on the import tree. I may need some help adding tests

[dlang-bot]

Fix	Bugzilla	Description
✓	7016	local import does not create -deps dependency

[timotheecour]

Awesome, been waiting for this for a long time.

• Could you add a flag (off by default) to control this? (so no breaking change ; it is a breaking change because suddenly (because of recursion), it can lead to much longer compile time or broken compiles (say if a dependent import which previously wasn't going to be compiled has to be compiled)
• rdmd has --exclude=package and --include=package to control which dependency gets recursively compiled; i think the same logic can be used here for same reasons as 1st argument (maybe in a 2nd commit though, no point in delaying this)

[RazvanN7]

This commit solves the problem of infinite recursion caused by cyclic imports. I am not sure if this feature should be activated by another flag since by definition the "-deps" flag should list all dependencies (either local or global). A problem which I noticed is that if a module imports the same module N times in different scopes, the import is printed N times (this was true for the older version also). I am not sure if this is the de facto standard or it should be fixed, but either way that is a different problem.

A different question is : should std.* core.* and etc.* imports be ignored? Or should an --include/--exclude flag be added?

Any suggestions are welcome.

[UplinkCoder]

calling phobos inside dmd is a nono.
Since you are already using AA's you might as well use the dmd internal hash-table for strings.
it's in root.

[UplinkCoder]

Oh noes,
this is going to slow.

[RazvanN7]

I replaced the AA with the string-key hashtable in root.springtable. Hope it's ok now. Thanks for the tip

[RazvanN7]

I made a separate pool request that erases all ddmd. prefixes. For this PR I needed to import ddmd.root.stringtable, so I'm guessing there's gonna be some conflicts. I think that the faster #6489 is merged, the better.

[RazvanN7]

@MartinNowak I have no idea why the tests are failing. Locally, I don't have any problems when running the tests.

[RazvanN7]

@timotheecour do you think that if -deps is used in conjunction with -unittest, should the dependencies of unittests be printed too?

[timotheecour]

@timotheecour do you think that if -deps is used in conjunction with -unittest, should the dependencies of unittests be printed too?

unittest blocks should be treated as normal functions in that regard, so yes. That way, when rdmd uses -rdeps, rdmd -unittest foo.d will work as well as rdmd foo.d without giving link errors.

• dmd -deps behavior should not change for reasons given here: Fix Issue 7016 - local import does not create -deps dependency #6468 (comment)
• how about calling it: dmd -rdeps (and also -rdeps=<filename>) for recursive deps
• as said here (Fix Issue 7016 - local import does not create -deps dependency #6468 (comment)) we could have:

dmd -rdeps-include=package
dmd -rdeps-exclude=package