dmd -deps fun1.d fun2.d produces very different results when order of source files changes

[dlangBugzillaToGithub]

Timothee Cour (@timotheecour) reported this on 2018-01-20T08:37:59Z

Transferred from https://issues.dlang.org/show_bug.cgi?id=18271

CC List

• Jonathan Marler (@marler8997)
• Timothee Cour

Description

$ time ~/Downloads/dmd2_074/osx/bin/dmd     -c -deps=/tmp/z02.txt fun2.d fun3.d && wc -l /tmp/z02.txt
cpu 0.052 total
     109 /tmp/z02.txt

$ time ~/Downloads/dmd2_074/osx/bin/dmd     -c -deps=/tmp/z02.txt fun3.d fun2.d && wc -l /tmp/z02.txt
cpu 0.055 total
     109 /tmp/z02.txt

with dmd_075 up to today(v2.077.1) I get:

$ time dmd     -c -deps=/tmp/z02.txt fun3.d fun2.d && wc -l /tmp/z02.txt
cpu 0.784 total
    1137 /tmp/z02.txt
$ time dmd     -c -deps=/tmp/z02.txt fun2.d fun3.d && wc -l /tmp/z02.txt
cpu 0.058 total
     107 /tmp/z02.txt

Note also that (depending on order), dmd produces much more output (and is slower) than before; I'm guessing (depending on order), it will do semantic analysis on function local imports; in any way, the order-dependency is a bug.


```
// fun2.d
void test2(){
        import fun3;
        test3;
}
// fun3.d
void test3(){
        import std.stdio;
        writeln(__FILE__);
}
```

[dlangBugzillaToGithub]

timothee.cour2 commented on 2018-01-20T08:38:31Z

likewise with -deps (instead of -deps=file)

[dlangBugzillaToGithub]

timothee.cour2 commented on 2018-01-20T09:23:37Z

according to @marler8997 on https://github.com/dlang/tools/pull/291#issuecomment-359156301

> I think this may be by design. It only performs the full semantic analysis on modules imported by the first module given on the command line. I remember seeing the code do this and I thought it was odd but I assumed there was a reason for this.


> https://github.com/dlang/dmd/blob/f947c0881432988dcd8cd80d5abe71e4c0463867/src/dmd/mars.d#L822

> This is where the extra semantic analysis is done when the -deps flag is used. As you can see, only module[0].aimports is being scanned. This is either a bug or by design. If it's a bug, then the fix is likely to loop over Modules.modules instead of modules[0].aimports.


-----
* this is not documented in -deps (and also not in dmd changelog)
* what's a use case for doing it only on the 1st module?
here's a use case for doing it on all files passed on cmdline:

```
// main.d:
extern(C) void fun();
import other1;
void main(){fun();}

// mylib.d:
import other2;
extern(C) void fun(){}

// cmd line
dmd -deps main.d mylib.d
```

Would be nice to have as orthogonal features as possible;
could we have:
-i mean recurse on imports (while respecting -i=pattern)
-deps mean output dependencies (on whatever's being analyzed)

[dlangBugzillaToGithub]

johnnymarler (@marler8997) commented on 2018-01-20T20:01:08Z

> Would be nice to have as orthogonal features as possible;
> could we have:
> -i mean recurse on imports (while respecting -i=pattern)
> -deps mean output dependencies (on whatever's being analyzed)

-i currently means, include imported modules into the compilation as if they were given on the command line.  this is orthogonal to "recurse on imports", so I'm confused why you would want to combine these?