generate code for modules in DFO

[WalterBright]

The backend inliner relies on the code for functions to be inlined to be already generated. To that end, the modules presented to the code generator should be presented in depth-first-order to maximize the possibilities for inlining.

It still won't be able to inline functions for which code is not generated, as modules not listed on the command line. This seems to be a costly to overcome problem. Does gdc or ldc resolve it?

It also won't be able to inline functions that appear later in the source file than the function that wants to inline them. The functions in a module would also have to be in DFO order.

[dlang-bot]

Thanks for your pull request, @WalterBright!

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

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#16260"

[thewilsonator]

It still won't be able to inline functions for which code is not generated, as modules not listed on the command line. This seems to be a costly to overcome problem. Does gdc or ldc resolve it?

that is what link time optimisation is for.

[WalterBright]

@thewilsonator cheaters! :-)

[ibuclaw]

@WalterBright there is no cross-module inlining in single-module compilation. There are a couple tricks to help it though.

For example, pragma(inline) functions are lazily codegen'd into every module that references them.

[WalterBright]

I'm so tired of utterly useless error messages like this:

1 modules passed unittests
make[2]: Leaving directory 'D:/a/1/s/druntime/test/stdcpp'
make[1]: Leaving directory 'D:/a/1/s/druntime'
##[error]Cmd.exe exited with code '5'.
Finishing: Build and test

after a thousand lines of useless information.

[WalterBright]

For example,

##[error]Cmd.exe exited with code '5'.

what is that coming from? I try:

grep -r Cmd *

from dmd/compiler and get no hits.

The purpose of a test suite is not just to test things. The purpose is to make it easy to find where the problem is. Our test suite makes that a miserable and extremely time-consuming experience. We wouldn't accept such error diagnostics from the compiler, why do we accept it from the test suite?

[RazvanN7]

@WalterBright I don't know whether you fixed the error or not, but I'm not seeing the error you are mentioning. I see that Azure is failing 2 runnable tests [1]:

• runnable\profilegc_stdout.d
• runnable\testarray.d

[1] https://dev.azure.com/dlanguage/dmd/_build/results?buildId=41716&view=logs&j=47916d67-4a7b-51e4-ebf4-f45083e4cd9e&t=d91376b7-b334-5ef4-b4c4-1689098bebd2

There's also a bunch of buildkite projects failing, but I can't tell id they're related or not.

[WalterBright]

@RazvanN7 thanks I'll check into these errors.