Avoid the need of calling initDMD() in library code

[wilzbach]

Requiring library code to call your initializers was popular in the 90s, it isn't anymore.
Let's go ahead with a good example.
(also DMD as a library is quite similar to Phobos and there isn't any manual interaction needed when calling a function in Phobos)

I initially used initOnce as @andralex put a lot of work in avoid module constructor at Phobos (see e.g. dlang/phobos#5421, dlang/phobos#5423, ...), but that was only to ease uses when Phobos is used with -betterC, which won't be the case for the DMD DUB package. After all, it's intended for people writing language tools in D.

See also: #7789

[dlang-bot]

Thanks for your pull request, @wilzbach!

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.

[jacob-carlborg]

I'm not sure I like this. The original reason why it's necessary to call initDMD is that I said no to using a module constructor. What I said back then was that there might be a use case/possible to use multiple instances of the compiler in the future. I'm not sure if that's worth striving for.

An alternative would be to wrap everything in a class that needs to be instantiated, Frontend or Compiler.

[PetarKirov]

Yes, we should strive for making the compiler as reusable as a simple object with constructor and destructor, so +1 for having a Compiler class/struct.

[wilzbach]

Not sure whether that makes sense as long as the compiler still uses globals - it would create a false abstraction.
On the other hand, we need to start somewhere and we could already store state like the import paths...

[jacob-carlborg]

Not sure whether that makes sense as long as the compiler still uses globals - it would create a false abstraction.

True. But changing the API (if needed in the future) is usually quite difficult. Another idea is to use a singleton. The user basically gets access to an instance but can not create new instances. Later we can lift that restriction and I don't think that would break the API.

[PetarKirov]

I am quite aware that we're pretty far from having a reusable Compiler RAII object. I'm just saying that we should strive to change the architecture.

[wilzbach]

there might be a use case/possible to use multiple instances of the compiler in the future. I'm not sure if that's worth striving for.

FYI @rikkimax has been toying with resetting DMD's global state https://forum.dlang.org/post/p4n5gk$19qf$1@digitalmars.com

[rikkimax]

We don't need to support multiple instances of the compiler, and I do think that is a bit too much work given the current architecture.

But we do need to be able to reset it back to a freshly new initialised state resonably cheaply.

What this means is in a tooling scenario, you don't have to unload+load a shared library or stop+create an executable to just get a new state.

My experiments were pretty short lived, not even dub build was working for me, but I do think I got the basic idea out in my included patch.

[Geod24]

We don't need to support multiple instances of the compiler, and I do think that is a bit too much work given the current architecture.

I experimented with DMD as a library years ago. This was literally the first thing I needed...

@wilzbach : I fully agree with @jacob-carlborg and @ZombineDev here that we should not use module constructors, and instead everything should be encapsulated as an object.
I know that there's tons of global state at the moment and we're far away from this, but this does not go in the right direction.

Since this has been stale for 8 months, and is pretty little code, I'm going to close to reduce backlog.