Avoid the need of calling initDMD() in library code#7800
Avoid the need of calling initDMD() in library code#7800wilzbach wants to merge 1 commit intodlang:masterfrom
Conversation
|
Thanks for your pull request, @wilzbach! Bugzilla referencesYour PR doesn't reference any Bugzilla issue. If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog. |
| shared static this() | ||
| { | ||
| initDMD(); | ||
| } |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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...
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
FYI @rikkimax has been toying with resetting DMD's global state https://forum.dlang.org/post/p4n5gk$19qf$1@digitalmars.com |
|
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. |
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. Since this has been stale for 8 months, and is pretty little code, I'm going to close to reduce backlog. |
6 participants
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
initOnceas @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