Fix Issue 23597 - .di files not compatible with -i

[CyberShadow]

Makes .di files more useful for e.g. Deimos projects.

[dlang-bot]

Thanks for your pull request, @CyberShadow!

Bugzilla references

Auto-close	Bugzilla	Severity	Description
✓	23597	enhancement	.di files not compatible with -i

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + dmd#14783"

[thewilsonator]

this is such a trivial change, did you want to do this straight stable? Also rebase to fix CI errors.

[dkorpel]

If I understand correctly, this change makes -i not compile .di imports anymore. How does that solve a missing reference at link time? I would expect this has the opposite effect.

[RazvanN7]

-i promotes included modules to root modules, therefore the instance of fun is then generated in the object file of the .di file.

[dkorpel]

the instance of fun is then generated in the object file of the .di file.

So dmd doesn't pass object files from .di files to the linker?

[RazvanN7]

I think that object files are never generated for .di files.

[CyberShadow]

Also rebase to fix CI errors.

Thanks, done.

this is such a trivial change, did you want to do this straight stable?

I am slightly worried about regressions for the case where a .d file is compiled separately, a .di file is generated from it, and then used to compile the main program, then linking the .d file's object file.

[CyberShadow]

If I understand correctly, this change makes -i not compile .di imports anymore. How does that solve a missing reference at link time? I would expect this has the opposite effect.

So what this does is essentially tell the compiler that the corresponding module is not going to be compiled. .di files are already never compiled by themselves.

There are two cases for .di files:

1. There is a .d file which contains the implementation, and a .di file which contains just the declarations. This is equivalent to C's classic .c + .h pairing.

   For this case, the compiler can assume that anything declared in the .di file will be compiled separately and available at link time.

2. There is no .d file, there is just a .di file. This is equivalent to "header-only" C libraries, and is what we want to do with Deimos (because they attempt to be a 1:1 port of .h files in /usr/include).

   For this case, the compiler needs to be told that there will not be a .d file, and things like template instantiations will not be available at link time, so anything which is not explicitly implementation-less should be compiled and built as part of the current compilation.

What this change does is that it changes how the compiler treats imported .di files when -i is specified from 1 to 2.

In theory this might be a breaking change for the intentional 1 case, but considering that the -i feature is rarely used in practice (Dub doesn't use it, which is a shame because it can greatly speed up builds and reduce the filesize of built binaries), and combined with also the limited use of .di files, I think the real-world effect of this is going to be minimal.